Ye Xiaolong <xiaolong.ye@xxxxxxxxx> writes:
> ---1---o---A
> / \ /
> ---O X
> \ / \
> ---2---o---o---B
>
> For this criss-cross merges, as neither merge base(like 1) is better
> than the other(both 1 and 2 are 'best' merge bases), I think it should
> be fine to pick a random one as base commit(Or you prefer to show all of
> them?) and I'll add this part of discusstion into documentation.
I think you should error out; it would give you blatantly wrong to
pick either one at random.
Suppose A is where your remote-tracking branch is, and B is where
the user started working on her serie. We are sending patches built
on top of B (not depicted) with "format-patch --base=A B..".
If you picked '1' as the base, you'll include commits on the ===
stretch as prerequisite patches (think of any non-merge --o-- in the
picture to consist of multiple commits), but you won't be showing
what the merge 'M' between '1' and '2' did to the tree of '1' to
arrive at the resulting tree of 'M'.
---1---o---A
/ \ /
---O X
\ / \
---2---M===o===B...your.patches.here...
If you picked '2' as the base, you'll include commits on the ===
stretch as prerequisite patches, but again you won't be showing what
the merge 'M' between '1' and '2' did to the tree of '2' to arrive
at the resulting tree of 'M'..
---1---o---A
/ \ /
---O X
\ / \
---2===M===o===B...your.patches.here...
So either case, you cannot rebuild the tree of B by going from the
base and piling on patches in such a case, because you won't have
"patch" for merge 'M'.
--
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