GNU-style ChangeLog merge driver for Git (was: Re: git: avoiding merges, rebasing)

[Benoit SIGOURE <tsuna@lrde.epita.fr>]

[-- Attachment #1: Type: text/plain, Size: 3366 bytes --]

On Oct 9, 2007, at 2:03 PM, Bruno Haible wrote:

> Hello Benoit,
>
> Thanks for working on this. But this merge driver has a few major  
> nits.
>
>
> 1) While my ChangeLog file was locally unmodified but some pulled  
> in commits
>    should modify it, "git pull" stopped and said:
>
> ChangeLog: needs update
> fatal: Entry 'ChangeLog' not uptodate. Cannot merge.
>
> [I cannot swear on this, because I did not do a "git status" before  
> the
> "git pull", but this is in a directory where I usually have no  
> pending diffs.]

I'll check but I'm afraid that Git bails out before actually trying  
the merge driver.

>
> The ChangeLog in question is the one from gnulib
> (git clone git://git.sv.gnu.org/gnulib).
>
>
> 2) This "merge driver" did much more than sorting in a merge: it  
> sorted the
> entire file! In doing so,
>   - It changed the order of ChangeLog entries in a way that does  
> not represent
>     the historical commit order.
>   - For ChangeLog entries with multiple contributors, it shuffled  
> around these
>     extra contributors to other ChangeLog entries.
>   - Near the end of the file, it made a change that I cannot explain.
>
> Find attached a context diff of all the bad changes that it did.
>

Yes, it's pretty stupid, I hacked this in a hurry.  I'll try to  
improve it so that it doesn't have these undesired side-effects.

>
> In my opinion, a merge driver should not do changes to the file except
> in the range of lines where the conflict occurred. For a ChangeLog  
> driver,
> all uncommitted entries should be collected at the top of the file,  
> because
> 1. ChangeLogs are kept in the order of historical commit in the  
> central
>    repository,
> 2. other developers always look at the top of the ChangeLog; if a  
> ChangeLog
>    entries is inserted second or third after some already present  
> entries,
>    the danger is too high that the change gets unnoticed.
>
> So "git-merge-changelog OLD CURRENT OTHERS" should IMO do the  
> following:
> 1) Collect the changes between OLD and HEAD (I don't know if that  
> is CURRENT
>    or OTHERS?), in two categories:
>      - added entries,
>      - changed and removed entries.
> 2) Back out the added entries, keeping only the changed and removed  
> entries
>    as modifications.
> 3) Do a normal merge between this and the pulled in remote branch  
> (I don't
>    know if that is OTHERS or CURRENT?). If that merge gives a  
> conflict,
>    bail out.
> 4) Insert the added entries at the top, in the same order as they were
>    originally (no sorting).
>
> Bruno
> <git-merge-changelog-blunder>

OK I'll try to rework the driver so that it implements this.  It will  
take some time though, I'm quite busy these days.
Akim Demaille would also like it to squash the commits added by the  
merge (the new commits in OTHERS):

YYYY-MM-DD  Author  <who@where.com>

	Merge whatever:

	YYYY-MM-DD  Someone Else  <foo@bar.com>
	Some change.
	* FileChanged.c: Whatever.

	YYYY-MM-DD  Who Cares  <who@cares.com>
	Some other change.
	* OtherFile.c: Do it.

I thought this was mandated by the GNU Coding Standards but I  
checked, it doesn't say anything about merges.  Would this sort of  
strategy be useful to you?  Should it be default (or enabled by some  
--squash option)?

Cheers,

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]