Junio C Hamano [off-list ref] writes:
quoted
I prepared a patch to reject such a request when there are more than one
merge base (see below---it is against 1.6.4 maintenance track). While I
think giving _one_ possible explanation of what you did since you forked
would be better than rejecting, which I'll try in a separate message, but
at the same time it may be misleading to give such an output without
telling the user that we chose one merge base at random to diff against
it.
And this is the other one (not relative to the previous patch) that shows
diff since one randomly chosen merge base.
Thanks for the detailed explanation and patches!
Personally I like this behavior better than erroring out when there are multiple
merge bases, even though the result is unpredictable. We were using 'diff
A...B' in a script that users run to submit their changes to a continuous
integration server, to check whether they had any actual changes to submit. In
that context, we don't care whether the output makes sense, we only care whether
there is any output.
The script has been changed to avoid using the A...B syntax now, so it's not a
big deal if you prefer to just error out in this situation. But FWIW, this
patch also has the advantage that it makes the code match the existing
documentation... assuming that the randomly chosen merge base is the same one
that 'git merge-base' would print.
James