Re: GNU-style ChangeLog merge driver for Git

[James Youngman]

On Feb 12, 2008 2:41 AM, Micah Cowan <address@hidden> wrote:

> OTOH, a more difficult problem might be: how do you go about fixing
> erroneous commit logs? In Subversion and CVS, this can be dealt with if
> you have appropriate privileges; but in Mercurial at least (and probably
> Git as well?), the commit log is a part of the changeset; you can't
> change it without making it a wholly separate changeset. So if it's
> already been published, it'd be impractical to correct; it'd require
> some gnarly post-processing, then, to make the corrections.

You can use git filter-branch --msg-filter=foo, with appropriate foo.
 However, the resulting commits will no longer be the ancestors of any
changes other people have in their own repository, requiring them
probably to do a (non-fast-forward?) fetch and then rebase their
changes.   All in all it's very awkward, and I'm not sure I fully
understand the downsides of having to do it.

> Then again, there's a different sort of problem that's been irking me
> somewhat with making ChangeLog entries (whether generated or manual),
> ever since I started using DRCSses, and that is that the DAG nature of
> change history in a DRCS doesn't map cleanly to a linear ChangeLog. That
> is, you can no longer depend, for changes listed A, B, C, D, that all of
> the changes A, B, and C were present at the time change D was made. This
> can lead to false impressions about the context of a change entry, or of
> the history of a particular section of code. This isn't causing me major
> headaches

It does cause me major headaches, particularly when dealing with long
sequences of significant but not-yet-merged changes.  For example,
merging Leslie Polzer's Summer of Code changes for findutils is going
to require almost as much work making the ChangeLog work as in merging
all of the rest of the code combined.   (I know this because I already
did a few trial merges).   This isn't Leslie's fault at all; he
complied with the GNU coding standards; it's the nature of ChangeLog
files.  However, I have yet to try out the merge-changelog driver.

I used to avoid this problem by runing rcs2log (specifically, Emacs's
vc-update-change-log command) on the CVS repository for a previous
project.  However, I found that the username mappings didn't always
work as I wished for CVS, and the changelog messages were typically
not detailed enough.  I found the more disciplined format of ChangeLog
an improvement.

These days, I use a ChangeLog-format change message as my GIT commit
message, which solves most of the problem.  It's still not that
convenient, sadly, because
(1) I have not yet taken the time to wrap Emacs' add-change-log-entry
so that it creates a new file for use with git commit -F (instead I
just cut the change off the head of ChangeLog and write the extract to
.git/cl-desc), and
(2) I still need to manually prepend the GIT commit message to
ChangeLog when applying changes from GIT to the CVS repository.

I'm not sure what I will do in place of (2) when I migrate the public
findutils repository from CVS to GIT, though.   Maybe just using the
merge driver or auto-generating the ChangeLog will be enough.

James.