git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Date
Apr 16, 2012, 21:32 UTC
Message-ID
<20120416233218.54daa2f6@gmail.com>
In-Reply-To
<CA+55aFyAsF4jNvNMKC6divzAfyVmgrHvxJtnX0fjkpp_bLHkPQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 29 quoted lines
> 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 {
Previous: Linus TorvaldsNext: Linus Torvalds
Message 14 of 22 in “Re: What's cooking in git.git (Apr 2012, #05; Thu, 12)”
  1. Michal KiedrowiczApr 16, 2012
  2. Linus TorvaldsApr 16, 2012
  3. Junio C HamanoApr 16, 2012
  4. Linus TorvaldsApr 16, 2012
  5. Junio C HamanoApr 16, 2012
  6. 0/4 merge: reduce set of parents consistentlyJunio C Hamano, Apr 17, 2012
  7. 1/4 git-merge: test octopus with redundant parentsJunio C Hamano, Apr 17, 2012
  8. 2/4 builtin/merge.c: remove "remoteheads" global variableJunio C Hamano, Apr 17, 2012
  9. 3/4 builtin/merge.c: collect other parents earlyJunio C Hamano, Apr 17, 2012
  10. 4/4 builtin/merge.c: reduce parents earlyJunio C Hamano, Apr 17, 2012
  11. Junio C HamanoApr 16, 2012
  12. Linus TorvaldsApr 16, 2012
  13. Linus TorvaldsApr 16, 2012
  14. Michał KiedrowiczApr 16, 2012
  15. Linus TorvaldsApr 17, 2012
  16. git-merge: Reduce heads before trying to merge themMichał Kiedrowicz, Apr 17, 2012
  17. Junio C HamanoApr 17, 2012
  18. Linus TorvaldsApr 17, 2012
  19. Junio C HamanoApr 17, 2012
  20. Michał KiedrowiczApr 18, 2012
  21. Junio C HamanoApr 18, 2012
  22. Junio C HamanoApr 19, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.