[webkit-dev] changelogs: a reprise

[David Levin]

I think someone already wrote this for you:
  http://ivanz.com/2009/03/19/git-automatic-smart-changelog-merging/
which referrs to

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c;h=b9ab42947b2590b31d69544d566e1f6b04a90100;hb=HEAD

I was using this for a while and it seemed to work well when you do git
rebase. If you do a merge, your changelog entry will end up after the merged
changelog entries which makes sense but isn't what I wanted typically.

dave

PS I only stopped out of laziness. Setting this up vs typing
resolve-ChangeLog --continue (which isn't that big of a deal for me).


On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer <ddkilzer at webkit.org> wrote:

> On Mon, January 25, 2010 at 10:35:00 PM, Chris Jerdonek wrote:
>
> > I was reading through the old "I HATE CHANGELOGS" messages from August:
> >
> > https://lists.webkit.org/pipermail/webkit-dev/2009-August/thread.html
> >
> > The discussion attracted a lot of interest and ideas, but it looks
> > like it died out without reaching any conclusion.
> >
> > It seems like the tools around ChangeLogs have improved somewhat since
> > then, but we still have, for example, the fundamental
> > conflict-on-commit annoyance.
> >
> > What do people think about these two possibilities for short- and
> > mid-term strategies, respectively?
> >
> > (1) Provide a simple wrapper around "svn commit" and "git svn dcommit"
> > that encapsulates the retry logic in case of ChangeLog conflicts.
> > This way, the end-user will never have to resolve ChangeLog conflicts
> > on commit.  Higher-level commands like webkit-patch could use this
> > under the hood, if they wanted, to cope with race conditions.
> >
> > (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.  The
> > commands in (1) would be smart enough to read the new ChangeLog
> > information from these alternate locations, and then add the ChangeLog
> > information to the ChangeLog files at the last moment -- prior to
> > commit.  Users of this workflow would never have to resolve ChangeLog
> > conflicts during the review process, since new entries are stored
> > separately.  It may be easiest to support this new workflow for Git
> > users first.
> >
> > The second idea is essentially Ojan's proposed modification of one of
> > Maciej's ideas:
> >
> > https://lists.webkit.org/pipermail/webkit-dev/2009-August/009708.html
> >
> > It is a mid-term rather than short-term strategy since it involves
> > changes to several scripts (e.g. svn-create-patch) to allow the review
> > process to support this alternate workflow.
>
>
> I think I mentioned this before, but for git users, this can be solved in
> the short term by a merge driver that uses resolve-ChangeLogs (once it knows
> how to be invoked by git as a merge driver):
>
> <
> http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_built_in_merge_drivers
> >
>
> I started hacking on resolve-ChangeLogs to be invoked by three arguments
> this way, but haven't had time to finish it.
>
> 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.
>
> Dave
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100126/99f55ac4/attachment.html>