I'm hitting bad merges with (non interactive) git rebase
when a hunk is merged pre-maturely into an inexact match
when there's fuzz.
The following shell script reproduce this with
git version 1.6.2.1:
#!/bin/sh
rm -rf test_file .git
git init
cat >test_file <<EOF
struct one {
line 1;
line 2;
line 3;
line 4;
line 5;
line 6;
line 7;
};
struct two {
line 1;
line 2;
line 3;
line 4;
line 5;
line 6;
line 7;
};
EOF
git add test_file
git commit -m test_file
git am <<EOF
From: Benny Halevy <redacted>
Subject: change struct two
diff --git a/test_file b/test_file
--- a/test_file
+++ b/test_file
@@ -12,7 +12,7 @@ struct two {
line 1;
line 2;
line 3;
- line 4;
+ LINE 4;
line 5;
line 6;
line 7;EOF
git checkout -b test_branch HEAD^
{ for i in {1..10}; do echo fuzz $i; done; echo; cat test_file; } > fuzz_file
mv fuzz_file test_file
git commit -a -m fuzz
git rebase --onto test_branch master^ master
if [ $(awk '/LINE/ {print NR}' test_file) != 26 ]; then
echo 1>&2 $0: test failed
exit 1
else
echo 1>&2 $0: test succeeded
fi
Benny Halevy wrote:
I'm hitting bad merges with (non interactive) git rebase
when a hunk is merged pre-maturely into an inexact match
when there's fuzz.
[...]
{ for i in {1..10}; do echo fuzz $i; done; echo; cat test_file; } > fuzz_file
[...]
git rebase --onto test_branch master^ master
git-am, and by extension rebase, by default doesn't take history into
account. It just applies the patches "blindly". Thus, there's no way
to know which series of 'line N' you really wanted it to go onto.
To avoid this issue, use the -m option to git-rebase so that it uses a
"real" merge. (You can achieve similar effects for git-am with the -3
option.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
On Mar. 23, 2009, 15:54 +0200, Thomas Rast [off-list ref] wrote:
Benny Halevy wrote:
quoted
I'm hitting bad merges with (non interactive) git rebase
when a hunk is merged pre-maturely into an inexact match
when there's fuzz.
[...]
quoted
{ for i in {1..10}; do echo fuzz $i; done; echo; cat test_file; } > fuzz_file
[...]
quoted
git rebase --onto test_branch master^ master
git-am, and by extension rebase, by default doesn't take history into
account. It just applies the patches "blindly". Thus, there's no way
to know which series of 'line N' you really wanted it to go onto.
To avoid this issue, use the -m option to git-rebase so that it uses a
"real" merge. (You can achieve similar effects for git-am with the -3
option.)
OK. -m indeed helps and I'm certainly going to adopt it for my rebase scripts.
git rebase -i does too, BTW.
I would expect though that the default mode for automatic rebase would be
the strictest and safest...
Benny
On Mar. 23, 2009, 16:06 +0200, Benny Halevy [off-list ref] wrote:
On Mar. 23, 2009, 15:54 +0200, Thomas Rast [off-list ref] wrote:
quoted
Benny Halevy wrote:
quoted
I'm hitting bad merges with (non interactive) git rebase
when a hunk is merged pre-maturely into an inexact match
when there's fuzz.
[...]
quoted
{ for i in {1..10}; do echo fuzz $i; done; echo; cat test_file; } > fuzz_file
[...]
quoted
git rebase --onto test_branch master^ master
git-am, and by extension rebase, by default doesn't take history into
account. It just applies the patches "blindly". ...
git am, in contrast to git rebase, errs on fuzz and you'll need to
apply the patch manually. It might be annoying, but it'd be safer
if git rebase would either stop on fuzz too or revert to using
merge strategies (same as using git rebase -m) by default.
quoted
... Thus, there's no way
to know which series of 'line N' you really wanted it to go onto.
Well, there's the hunk header.
Benny
quoted
To avoid this issue, use the -m option to git-rebase so that it uses a
"real" merge. (You can achieve similar effects for git-am with the -3
option.)
OK. -m indeed helps and I'm certainly going to adopt it for my rebase scripts.
git rebase -i does too, BTW.
I would expect though that the default mode for automatic rebase would be
the strictest and safest...
Benny
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html