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