Re: [Archer] Merging lessons

[Jim Meyering <jim at meyering dot net>]

Tom Tromey <tromey@redhat.com> wrote:
...
> Jan> Should Archer submit a full FSF changelog history of the branch
> Jan> being checked-in FSF GDB or just the final patch changes?  Or
> Jan> should be maintained the FSF changelog style for Archer and then
> Jan> written a new FSF changelog entry for the FSF GDB merge?
>
> I think next time I am going to just have a separate ChangeLog.branch
> on my branch, and then rewrite it into a single ChangeLog whenever I
> push upstream.

Hi Tom,

I find maintaining a ChangeLog file to be too burdensome.  Using a VC'd
ChangeLog makes it so what should be trivial day-to-day operations
(e.g., reordering change-sets, rebasing) are almost guaranteed to
provoke merge conflicts.  In maintaining coreutils, I compromised: the
ChangeLog still exists, but only virtually, as a sequence of log entries.
However, there's a pretty good script to convert commit-log entries into
ChangeLog entries.  And I write commit log entries knowing how they'll
be converted.  Simple rules and incomplete commit hooks help ensure that
the result is reasonable.

At 'make dist' time, a ChangeLog file is automatically generated from
commit logs and inserted into the resulting tarball.  To do that, I use
this rule in Makefile.am:

gen_start_date = 2008-02-08
.PHONY: gen-ChangeLog
gen-ChangeLog:
        if test -d .git; then                                           \
          $(top_srcdir)/build-aux/gitlog-to-changelog                   \
            --since=$(gen_start_date) > $(distdir)/cl-t;                \
          rm -f $(distdir)/ChangeLog;                                   \
          mv $(distdir)/cl-t $(distdir)/ChangeLog;                      \
        fi

gitlog-to-changelog comes from gnulib.

If you choose to continue working with VC'd ChangeLog files,
consider using gnulib's git-merge-changelog.c.  That should
help alleviate the worst of your merge problems.

Jim