RE: [BUG] 'diff A...B' fails with multiple merge bases

From: Pickens, James E <james.e.pickens@intel.com>
Date: Jul 13, 2010, 01:16 UTC
Message-ID: <3BA20DF9B35F384F8B7395B001EC3FB36D000E3D@azsmsx507.amr.corp.intel.com>
In-Reply-To: <7viq4k6xea.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 10 quoted lines

>> 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