[Top][All Lists]
[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
git-merge-changelog-blunder
Description: Text Data
- Re: git: avoiding merges, rebasing, (continued)
- Re: git: avoiding merges, rebasing, Bruno Haible, 2007/10/02
- 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