Thread (7 messages) flat view 7 messages, 2 authors, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:53:36

Possibly related (same subject, not in this thread)

Linus Torvalds [off-list ref] writes:
quoted hunk
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) {
When everybody in remote_heads is an ancestor of the current HEAD,
finalize_parents() would have reduced parents to a single element list
with HEAD on it, and we are "already up-to-date".  Ok.

I wonder if use of remoteheads later in the same function are correct,
though.  We equate "!remoteheads->next" and "We are not doing octopus",
for example.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help