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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>

	Merge whatever:

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

	YYYY-MM-DD  Who Cares  <who@xxxxxxxxx>
	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: PGP.sig
Description: This is a digitally signed message part


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux