From: Junio C Hamano Date: Fri, 04 May 2018 02:19:31 GMT Subject: Re: [PATCH v3 09/12] get_short_oid / peel_onion: ^{tree} should be tree, not treeish Message-ID: In-Reply-To: <87wowlxko8.fsf@evledraar.gmail.com> Ævar Arnfjörð Bjarmason writes: > The reason I'm doing this is because I found it confusing that I can't > do: > > for t in tag commit tree blob; do ./git --exec-path=$PWD rev-parse 7452^{$t}; done > > And get, respectively, only the SHAs that match the respective type, but > currently (with released git) you can do: > > for t in tag commit committish treeish tree blob; do git -c core.disambiguate=$t rev-parse 7452; done Exactly. The former asks "I (think I) know 7452 can be used to name an object of type $t, with peeling if necessary--give me the underlying object of type $t". In short, the fact that you can write "$X^{$t}" says that $X is a $t-ish (otherwise $X cannot be used as a stand-in for an object of type $t) and that you fully expect that $X can merely be of type $t-ish and not exactly $t (otherwise you wouldn't be making sure to coerce $X into $t with ^{$t} notation). In *THAT* context, disambiguation help that lists objects whose name begins with "7452" you gave, hoping that it is a unique enough prefix when it wasn't in reality, *MUST* give $t-ish; restricting it to $t makes the help mostly useless. > 1) Am I missing some subtlety or am I correct that there was no way to > get git to return more than one SHA-1 for ^{commit} or ^{tree} before > this disambiguation feature was added? There is no such feature either before or after the disambiguation help. I am not saying there shouldn't exist such a feature. I am saying that breaking the existing feature and making it useless is not the way to add such a feature.