Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

From: Kyle J. McKay <mackyle@gmail.com>
Date: Sep 29, 2016, 14:36 UTC
Message-ID: <2FECD796-7B92-41BB-A0AF-57650FF7E78D@gmail.com>
In-Reply-To: <20160929132425.of7m5t4tsqcb6bbk@sigill.intra.peff.net>

On Sep 29, 2016, at 06:24, Jeff King wrote:

Show 11 quoted lines

>> If you are doing "git show 235234" it should pick the tag (if it  
>> peels to a
>> committish) because Git has already set a precedent of preferring  
>> tags over
>> commits when it disambiguates ref names and otherwise pick the  
>> commit.
>
> I'm not convinced that picking the tag is actually helpful in this  
> case;
> I agree with Linus that feeding something to "git show" almost always
> wants to choose the commit.

Since "git show" peels tags you end up seeing the commit it refers to (assuming it's a committish tag).

> I also don't think tag ambiguity in short sha1s is all that  
> interesting.

The Linux repository has this:

    901069c:
       901069c71415a76d commit iwlagn: change Copyright to 2011
       901069c5c5b15532 tag    (v2.6.38-rc4) Linux 2.6.38-rc4

Since that tag peels to a commit, it seems like it would be incorrect to pick the commit over the tag when you're looking for a committish.

Either 901069c should resolve to the tag (which gets peeled to the commit) or it should error out with the hint messages.

The Git repository has this:

    c512b03:
       c512b035556eff4d commit Merge branch 'rc/maint-reflog-msg-for- 
forced
       c512b0344196931a tag    (v0.99.9a) GIT 0.99.9a

So perhaps it's a little bit more interesting than it first appears.  :)

--Kyle