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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev