On Thu, Sep 29, 2016 at 07:36:27AM -0700, Kyle J. McKay wrote:
> On Sep 29, 2016, at 06:24, Jeff King wrote:
>
> > > 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).
Yes, but it's almost certainly _not_ the commit you meant. From your
example:
> c512b03:
> c512b035556eff4d commit Merge branch 'rc/maint-reflog-msg-for-forced
> c512b0344196931a tag (v0.99.9a) GIT 0.99.9a
If I'm looking for the commit c512b03, then it almost certainly isn't
v0.99.9a. That tag's commit is e634aec. Or another way of thinking about
it: you want to guess what the _writer_ of the note meant. Why would
somebody write "c512b03" when they could have written "v0.99.9a"? And
they certainly would not have written it if they meant "e634aec". :)
> > 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
Sure, I'm not surprised there's a collision. But I'd expect those to be
a tiny fraction of collisions. Here's the breakdown of object types in
my clone of linux.git:
$ git cat-file --batch-all-objects --batch-check='%(objecttype)' |
sort | uniq -c
1421198 blob
618073 commit
479 tag
2877913 tree
That's a hundredth of a percent tag objects. The chance that you have
_a_ 7-hex collision with a tag is relatively high. But the chance that
any given collision involves a tag is rather small.
-Peff
