threads / discuss / 18487

git rebase + fuzz = possible bad merge

Subject: git rebase + fuzz = possible bad merge

## tl;dr

4 messages between Mar 23, 2009 and Mar 23, 2009.

replies: 3people: 2as markdown or json

Benny Halevy· Mar 23, 2009, 10:41 UTC · lore

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 <bhalevy@panasas.com>
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
Thomas Rast· Mar 23, 2009, 13:54 UTC · re: Benny Halevy · lore

Re: git rebase + fuzz = possible bad merge

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
Benny Halevy· Mar 23, 2009, 14:06 UTC · re: Thomas Rast · lore

Re: git rebase + fuzz = possible bad merge

On Mar. 23, 2009, 15:54 +0200, Thomas Rast <trast@student.ethz.ch> wrote:
Show 17 quoted lines
> 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.)
>

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
Benny Halevy· Mar 23, 2009, 15:36 UTC · re: Benny Halevy · lore

Re: git rebase + fuzz = possible bad merge

On Mar. 23, 2009, 16:06 +0200, Benny Halevy <bhalevy@panasas.com> wrote:
Show 11 quoted lines
> On Mar. 23, 2009, 15:54 +0200, Thomas Rast <trast@student.ethz.ch> wrote:
>> 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".  ...

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.

>> ...  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
Show 17 quoted lines
>>
>> 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

← back to recent threads