On 12/16/2011 2:32 PM, SZEDER Gábor wrote:
Hi,
Briefly:
Neighboring areas of a file are modified in two branches. Git
merges the two branches without conflicts, but the result is not
semantically correct. How can I teach git to produce the correct
merge result when performing the same merge later on?
Longer:
The following commands create a file and two branches, both of them
modifying the file by adding lines in the same area:
git init cat>file<<\EOF 1
2 EOF git add file git commit -m file git apply<<\EOF diff --git
a/file b/file index 1c3e7efc..121366a2 100644 --- a/file +++ b/file
@@ -1,3 +1,5 @@ 1
+a + 2 EOF git commit -a -m a git checkout -b branch HEAD^ git
apply<<\EOF diff --git a/file b/file index 1c3e7efc..f2e91d4f 100644
--- a/file +++ b/file @@ -1,3 +1,6 @@ 1 +b + +c
2 EOF git commit -a -m 'b c' git checkout master
At this point I merge 'branch' and git produces the following
result:
$ git merge branch Auto-merging file Merge made by the 'recursive'
strategy. file | 3 +++ 1 files changed, 3 insertions(+), 0
deletions(-) $ cat file 1 b
c
a
2
Now, these changes and the merge above are the minimal receipe which
corresponds to a real merge I'm having trouble with at dayjob. Just
imagine that '1' and '2' are the beginning and end of a function,
'b' is the declaration of a new local variable, and 'a' and 'c' are
new code blocks. As it happens, the semantically correct result
would be the following:
1 b
a
c
2
i.e. 'a' must be executed before 'c'.
I corrected the merge result manually, but these two branches are
merged a couple of times a day into an integration branch, and they
will likely cook for a few weeks, which means a lot of merges, and a
lot of manual corrections. So I'm looking for a way to teach git to
produce the semantically correct merge result. Something like
'rerere' would be great, but of course I can't use 'rerere' in this
case, because there are no merge conflicts at all...
Any ideas? Did someone deal with similar issues before?
You can produce conflicts by implementing keyword expansion on "line 1"
(or whatever the first commentable line is in your language) of your
source changes during your pre-commit hook. We do a keyword expansion
on "user" (whomai) and "date" (date) keywords. This will cause "line 1"
to conflict on same file edits in a merge. As for trusting rerere, we
don't. We do it manually with kdiff3 as the mergetool. If rerere works
for you reliably in this scenario then I'd like to know about it.
v/r,
neal
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html