Jeff King <peff@xxxxxxxx> 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. > 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.
