I can phrase this in two ways and I'll start with the short way:
Why does a merge of a git submodule use as merge-base the commit that was
active in the merge-base of the parent repo, rather than the merge-base of
the two commits that are being merged?
The long question is:
A submodule change can be merged, but only if the merge is a
"fast-forward" which I think is a fair demand, but currently it checks if
it's a fast-forward from a commit that might not be very interesting
anymore.
If two branches A and B split at a point when they used submodule commit
S1 (based on S), and both then switched to S2 (also based on S) and B then
switched to S21, then it's today not possible to merge B into A, despite
S21 being a descendant of S2 and you get a conflict and this warning:
warning: Failed to merge submodule S (commits don't follow merge-base)
(attempt at ASCII gfx:
Submodule tree:
S ---- S1
\
\ - S2 -- S21
Main tree:
A' (uses S1) --- A (uses S2)
\
\ --- B' (uses S2) -- B (uses S21)
I would like it to end up as:
A' (uses S1) --- A (uses S2) ------------ A+ (uses S21)
\ /
\ --- B' (uses S2) -- B (uses S21)- /
And that should be legal since S21 is a descendant of S2.
/Daniel
--
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