Re: rev-list and "ambiguous" IDs

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 19, 2019, 01:24 UTC
Message-ID: <xmqq7e3w1wvg.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20191118120315.GB12766@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> I think that changes the meaning of GET_OID_COMMITTISH, though. Right
> now it means "if disambiguating, prefer a committish", but not "I can
> only accept a commit". So we would still happily return an unambiguous
> object that does not match that type.

Ah, OK, so I was stupid (not a news anymore ;-)

> And that is why "git -c
> core.disambiguate=committish show $short_blob" works, for example.

Yes, and it should work that way.

Show 26 quoted lines

> Perhaps a simple fix would just be for get_short_oid()'s error message
> to mention the disambiguation rule. E.g., something like:
>
>    $ git show abcd2
>    error: short SHA1 abcd2 is ambiguous
>    hint: We would have preferred a commit or tag pointing to a commit,
>    hint: but none were found. The candidates are:
>    hint:   abcd22f55e tree
>    hint:   abcd238df0 tree
>    hint:   abcd2b1cc8 blob
>
> or
>
>   $ git show abcd2
>   error: short SHA1 abcd2 is ambiguous
>   hint: We preferred a commit or tag pointing to a commit to other
>   hint: object types, but two candidates were found:
>   hint:   abcd22f55e commit
>   hint:   abcd238df0 commit
>   hint:   abcd2b1cc8 blob
>
> (optionally the second one could even not mention the blob, though I
> think with the lead-in sentence it's OK).
>
> The verbiage there isn't great (I was trying to avoid the jargon
> "committish"), but hopefully you get the point.

Yup, if we were to do anything, this is a much more sensible thing to do than make GET_OID_<TYPE> reject objects that are not of <TYPE>, I think.

Thanks for a dose of sanity.