On Sun, Apr 15, 2012 at 11:26 PM, Michal Kiedrowicz
<michal.kiedrowicz@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html