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
Linus Torvalds <torvalds@linux-foundation.org>
Date
Apr 16, 2012, 14:57 UTC
Message-ID
<CA+55aFwkf2bOLmUCU+_pSg0OzGyfQ1x-Cy_CiczpJN3zsThNWg@mail.gmail.com>
In-Reply-To
<20120416082641.5d239ef6@mkiedrowicz.ivo.pl>

On Sun, Apr 15, 2012 at 11:26 PM, Michal Kiedrowicz <michal.kiedrowicz@gmail.com> wrote:

Show 5 quoted lines
>
> Heh, this seems to fix the issue I reported in [1], except... it
> doesn't work for the testcase I posted :).  The problem is that this
> commit makes Git 'fast-forward' to the first commit from remoteheads,
> not from the reduced heads.
Ack, good catch.

Thinking some more about this thing, I think we have a similar issue with the "Already up-to-date." thing.

It too had the "only one remote-head" test, which is wrong - what if you try to do a octopus merge with *two* commits that are different, and are both in the past? It will fail the "Already up-to-date" test, and then do a "fast-forward" to the first remote parent, if I read the code right..

So I think the "Already up-to-date" case should also be fixed, and in fact it becomes much more natural now that we have finalized the parents: we just check whether the one remaining parent is the same as HEAD.

So Ack on Michal's patch, but I think we also should do the appended equivalent thing for the fast-forward test on top of it (it's white-space damaged, sorry).

Trivially tested with
    git merge HEAD^ HEAD^^
which did the wrong thing before, and now works.
                       Linus
---
 builtin/merge.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 016a4dbee3b5..28fb5c9d6ada 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1370,8 +1370,7 @@ int cmd_merge(int argc, const char **argv, const
char *prefix)

        if (!common)
                ; /* No common ancestors found. We need a real merge. */
-       else if (!remoteheads->next && !common->next &&
-                       common->item == remoteheads->item) {
+       else if (!parents->next && parents->item == head_commit) {
                /*
                 * If head can reach all the merge then we are up to date.
                 * but first the most common case of merging one remote.
Previous: Michal KiedrowiczNext: Junio C Hamano
Message 2 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.