[webkit-dev] changelogs: a reprise
ddkilzer at webkit.org
Thu Jan 28 08:13:02 PST 2010
On Thu, January 28, 2010 at 4:10:11 AM, Chris Jerdonek wrote:
> On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer wrote:
> >> (2) Consider phasing in support for an alternate workflow where new
> >> ChangeLog entries for the next commit are stored separately from the
> >> versioned ChangeLog files -- perhaps in individual .changelog files
> >> for Subversion users and in the commit message for Git users.
> > I'm not a big fan of wrapper scripts, mostly because I'll probably
> > forget about using them since I'm so used to using the basic
> > git/svn commands. (I guess svn-create-patch is a counter-argument
> > to that, but I rarely use svn directly anymore.)
> > Using .changelog-bugnum files should probably be optional if it's
> > implemented, e.g., tools should still be smart enough (or at least
> > as smart as they are today) to operate on ChangeLog files directly
> > if developers choose to continue doing that. I say that because
> > once there is a git merge driver for ChangeLog files, the need for
> > an alternative ChangeLog workflow drops to zero, at least for me.
> I ran into an issue today where "git diff" didn't generate me a patch
> with the ChangeLog portion in the standard format. Namely, the
> ChangeLog diff had non-empty leading context (which can happen since
> it doesn't run fixChangeLogPatch like the svn-create-patch wrapper
> script). Is there a way to address this issue for Git users without
> using wrapper scripts or a change to the ChangeLog workflow?
I'm not sure if there is a way to "fix up" patches when they're created using git-diff, e.g., some kind of diff hook. Note that there is no "loss of information" if a ChangeLog patch isn't fixed up immediately after it's created, so the fix-up can always happen when the patch is applied later. It just looks a little ugly in the meantime. :)
I also replied with more thoughts in Bug 32834.
More information about the webkit-dev