[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GNU-style ChangeLog merge driver for Git (was: Re: git: avoiding merges,
From: |
Benoit SIGOURE |
Subject: |
GNU-style ChangeLog merge driver for Git (was: Re: git: avoiding merges, rebasing) |
Date: |
Tue, 9 Oct 2007 20:19:51 +0200 |
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 <address@hidden>
Merge whatever:
YYYY-MM-DD Someone Else <address@hidden>
Some change.
* FileChanged.c: Whatever.
YYYY-MM-DD Who Cares <address@hidden>
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
PGP.sig
Description: This is a digitally signed message part
- Re: git: avoiding merges, rebasing, (continued)
- Re: git: avoiding merges, rebasing, Eric Blake, 2007/10/02
- stash clear, was Re: git: avoiding merges, rebasing, Johannes Schindelin, 2007/10/19
- Re: stash clear, was Re: git: avoiding merges, rebasing, Miles Bader, 2007/10/23
- Re: git: avoiding merges, rebasing, Benoit SIGOURE, 2007/10/02
- Re: git: avoiding merges, rebasing, Bruno Haible, 2007/10/03
- Re: git: avoiding merges, rebasing, Bruno Haible, 2007/10/03
Re: git: avoiding merges, rebasing, Benoit SIGOURE, 2007/10/08
Re: git: avoiding merges, rebasing, Benoit SIGOURE, 2007/10/08