Junio C Hamano <gitster@xxxxxxxxx> writes: >> 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 -- 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