On Tue, 9 Oct 2007, martin f krafft wrote:
>
> I am a little confused why the following yields a conflict:
Octopus merges are special. Don't use them unless you really know what
you're doing. And generally not even then ;)
> $ git merge master second
> Trying simple merge with bb5f1b4f3a8cbfcbc9dbc97cc823f3ca05db2db1
> Trying simple merge with 7370737ff3aa6540a425db015e194766d2cbda2e
> Simple merge did not work, trying automatic merge.
> Added d in both, but differently.
> error: Could not read .merge_file_mCwa4W
> ERROR: Merge conflict in d
> fatal: merge program failed
> Automatic merge failed; fix conflicts and then commit the result.
>
> I don't understand why these conflict. I mean, sure, it makes sense:
> after merging master, file d is at d2. Now when merging second, it
> tries to replace d by its ancestor, d1.
Right. It makes total sense, because an octopus merge is simply always
going to create a whole new merge commit that goes through the sources one
by one, and merges them in - and if you do that, then you get a conflict
in "d".
> What I don't understand is why Git does not understand that commit
> d is part of the path of arriving at d2, so when 'second' is merged,
> Git *should* really see that the change to file d in 'second' (d1)
> is an ancestor of the already present d2 commit, and *not* conflict.
>
> What am I misunderstanding here?
Octopus merges do *not* fast-forward. Maybe they should. But they don't.
So when the octopus merge starts merging in "master" into the "merger"
branch, it will *not* just fast-forward the branch to "master". Instead,
if will generate a new tree that is basically the merged state: but that
new tree is *not* the same as the master commit, it's literally a merge of
the two branches - which in practice means that it has the same *content*
as master, but it's not at that commit.
So that first stage of the octopus merge has gone fine, but it didn't
really do what you expected.
And so now we have a half-way done octopus merge, with the first branch
added. Now it merges in the second branch ("second"), and it *still* has
the merge base being the original merge base, namely "merger".
And from that standpoint, it really *is* a conflict.
I do think that
- octopus merges should probably refuse to happen when a branch isn't a
"merge" at all, but a fast-forward.
*or*
- we should make octopus-merges smarter, and for each branch that is a
fast-forward, it really just fast-forwards.
but I don't think the current behaviour is "wrong", it's just not what you
expected.
If you think of octopus merges as a really stupid thing where git will
mindlessly do a three-way merge based on the *current* state with all the
branches you name, then you get the current octopus merge. You just
expected it to be smarter than it is, probably because you compare it to
the *real* merge.
Linus
-
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
