[webkit-dev] changelogs: a reprise

[David Kilzer]

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.

<https://bugs.webkit.org/show_bug.cgi?id=32834>

Dave