This is the mail archive of the
mailing list for the Archer project.
Re: [Archer] Merging lessons
Tom Tromey <email@example.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.
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
if test -d .git; then \
--since=$(gen_start_date) > $(distdir)/cl-t; \
rm -f $(distdir)/ChangeLog; \
mv $(distdir)/cl-t $(distdir)/ChangeLog; \
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.