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