Re: What's cooking in git.git (Apr 2012, #05; Thu, 12)

["Michał Kiedrowicz" <michal.kiedrowicz@gmail.com>]

Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Apr 16, 2012 at 11:02 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Oddly, running that test in verbose mode seems to imply that it's the
> > *rebase* that succeeds, not the merges in that test. Maybe I'm reading
> > the test results wrong, I didn't really try to understand the test
> > itself ;(
> 
> Yes, it's the rebase that succeeds. "git log -g" in the trash
> directory shows that we ended up successfully rebasing J2:
> 
>   commit 5fc34ec1a8ed96664198fefc74121cd052b10861
>   Reflog: HEAD@{1} (C O Mitter <committer@example.com>)
>   Reflog message: rebase -i (pick): Merge made by the 'recursive' strategy.
>   Author: A U Thor <author@example.com>
>   Date:   Thu Apr 7 15:28:13 2005 -0700
> 
>       J2
> 
> while a successful test will fail that.
> 
> However, I don't actually see what changed.
> 
> Oh - one thing to note is that the *patch* of that successful rebase
> is empty. That may be the big clue: we successfully finish the merge
> without noticing that it didn't change any state, and we should have
> failed it as an empty commit. Hmm?
> 
>                    Linus

So, the difference is that `git merge --no-ff HEAD^` used to work, now
it doesn't because we reduce_heads() only if we allow fast-forward (and
even though there is just one remote we merge with, parents contains
two commits). So what about that trivial patch instead (discarding our
previous patches)?
---
diff --git a/builtin/merge.c b/builtin/merge.c
index 08e01e8..27e0026 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1346,6 +1346,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
 			allow_trivial = 0;
 	}
 
+	remoteheads = reduce_heads(remoteheads);
+
 	if (!remoteheads->next)
 		common = get_merge_bases(head_commit, remoteheads->item, 1);
 	else {