bug-gnulib
[Top][All Lists]
Advanced

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

Re: git: avoiding merges, rebasing


From: Bruno Haible
Subject: Re: git: avoiding merges, rebasing
Date: Tue, 9 Oct 2007 14:03:26 +0200
User-agent: KMail/1.5.4

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.]

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.


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

Attachment: git-merge-changelog-blunder
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]