Andreas Ericsson wrote: > Jakub Narebski wrote: > > Junio C Hamano wrote: >>> (1) while it merges other heads one-by-one, it gets conflicts on an >>> earlier one, before it even attempts to merge all of them. Recording >>> the heads that it so far attempted to merge in MERGE_HEAD is wrong >>> (the result won't be an Octopus the end user wanted to carete), and >>> recording all the heads the user gave in MERGE_HEAD is even more >>> wrong (it hasn't even looked at the later heads yet, so there is no >>> way for the index or work tree to contain anything from them). >>> >>> The above is hitting this case. [...] >> BTW. does it mean that "git merge a b" might be not the same as >> "git merge b a"? >> > > No. Git merges all the sub-things together and then merges the result > of that jumble into the branch you're on. > > Someone might have to correct me on that, but that's as far as I've > understood it. >From what I understand from above explanation, and from thread on git mailing list about better implementation of and documenting finding merge bases for multiple heads, I think octopus merge is done by merging [reduced] heads one by one into given branch. This means that "git merge a b" does internally "git merge a; git merge b" as I understand it. -- Jakub Narebski Poland -- 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
