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

On Sun, Apr 15, 2012 at 11:26 PM, Michal Kiedrowicz
[off-list ref] wrote:

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.