Hi Eric,
> Is it also worth addressing the root cause of this? After all, it was
> git-merge-changelog that created file1 with more than 1 exact copy in the
> first place (via the earlier round of merging); it seems like it would be
> better for git-merge-changelog to fail with a merge conflict if both
> contributors provide an identical entry surrounded by differing context,
> than to create a file with duplicate entries.
I don't think it is the role of a merge driver to do such a thing. The
merge driver is only there because the fundamental unit in a ChangeLog
file is not the line, but the entry.
If you have that situation in a line-based file, like AUTHORS or NEWS,
git would not have merged two distant lines with the same contents.
Therefore ChangeLog shouldn't be different.
Actually it is not wrong to have identical ChangeLog entries. I can
easily imagine a ChangeLog like this:
2009-04-23 Stepan Kasal
* doc/foo.texi: Fix typos in last commit.
2009-04-23 Bruno Haible
* doc/foo.texi (Topic2): New section.
2009-04-23 Stepan Kasal
* doc/foo.texi: Fix typos in last commit.
2009-04-22 Bruno Haible
* doc/foo.texi (Topic1): New section.
When you copy a commit from one branch to another (via "git rebase"
for example), git will automatically drop hunks that were already
contained in the new branch. Therefore when you use "git rebase", you
have to have an eye on the ChangeLog entries anyway, and fiddle with
them afterwards (through "git commit --amend" or equivalent).
Bruno
