On Thu, May 10, 2018 at 01:21:19PM +0900, Junio C Hamano wrote:
> When diagnosing such an error, we would give hints. The hint would
> show possible objects that the user could have meant with X. The
> ^{<type>} suffix given to it may be used to limit the hints to
> subset of the objects that the user could have meant with X;
> e.g. when there is an object of each of type blob, tree, commit, and
> tag, whose name begins with 7777, the short and ambiguous prefix
> 7777 could mean any of these four objects, but when given with
> suffix, e.g. 7777^{tree}, it makes useless for the hint to include
> the blob object, as it can never peel down to a tree object.
>
> If the tag whose name begins with 7777 in this example points
> directly to a blob, excluding that tag from the hint would make the
> hint more useful. I do not offhand know what the code does right
> now. I wouldn't call it a bug if such a tag is included in the
> hint, but if a change stops such a tag from getting included, I
> would call such a change an improvement.
I actually wondered this while writing an earlier response, and so I
happen to know: when we are looking for a treeish, the disambiguator
will actually peel a candidate tag and only accept one that peels to a
tree or commit. So we would omit the tag-to-blob entirely from
consideration (both as a candidate for ambiguity, and in the hint list).
-Peff
