threads / discuss / 39706

git name-rev not accepting abbreviated SHA with --stdin

Subject: git name-rev not accepting abbreviated SHA with --stdin

## tl;dr

6 messages between Jun 24, 2015 and Jul 4, 2015.

replies: 5people: 2as markdown or json

Sitaram Chamarty· Jun 24, 2015, 03:29 UTC · lore
Hi all,

"git name-rev" does not accept abbreviated SHAs if --stdin is used, though it works when the SHA is given directly on the command line:

    $ git version
    git version 2.4.3
    $ git name-rev --tags d73f544
    d73f544 tags/v3.6.3~29
    $ git name-rev --tags --stdin <<< d73f544
    d73f544

This *is* documented, but I'm curious why this distinction is made. Is it merely a matter of parsing or were there some other complications I am unaware of, which forced this distinction to be made?

thanks sitaram

Junio C Hamano· Jun 25, 2015, 00:11 UTC · re: Sitaram Chamarty · lore

Re: git name-rev not accepting abbreviated SHA with --stdin

Sitaram Chamarty <sitaramc@gmail.com> writes:
> This *is* documented, but I'm curious why this distinction is made.

I think it is from mere laziness, and also in a smaller degree coming from an expectation that --stdin would be fed by another script like rev-list where feeding full 40-hex is less work than feeding unique abbreviated prefix.

Sitaram Chamarty· Jun 25, 2015, 02:01 UTC · re: Junio C Hamano · lore

Re: git name-rev not accepting abbreviated SHA with --stdin

On 06/25/2015 05:41 AM, Junio C Hamano wrote:
Show 8 quoted lines
> Sitaram Chamarty <sitaramc@gmail.com> writes:
> 
>> This *is* documented, but I'm curious why this distinction is made.
> 
> I think it is from mere laziness, and also in a smaller degree
> coming from an expectation that --stdin would be fed by another
> script like rev-list where feeding full 40-hex is less work than
> feeding unique abbreviated prefix.

Makes sense; thanks. Maybe if I feel really adventurous I will, one day, look at the code :-)

Junio C Hamano· Jul 3, 2015, 17:36 UTC · re: Sitaram Chamarty · lore

Re: git name-rev not accepting abbreviated SHA with --stdin

Sitaram Chamarty <sitaramc@gmail.com> writes:
Show 12 quoted lines
> On 06/25/2015 05:41 AM, Junio C Hamano wrote:
>> Sitaram Chamarty <sitaramc@gmail.com> writes:
>> 
>>> This *is* documented, but I'm curious why this distinction is made.
>> 
>> I think it is from mere laziness, and also in a smaller degree
>> coming from an expectation that --stdin would be fed by another
>> script like rev-list where feeding full 40-hex is less work than
>> feeding unique abbreviated prefix.
>
> Makes sense; thanks.  Maybe if I feel really adventurous I will,
> one day, look at the code :-)

Sorry, but I suspect this is not 100% laziness; it is meant to read text that has object names sprinkled in and output text with object names substituted. I suspect that this was done to prevent a short string that may look like an object name like deadbabe from getting converted into an unrelated commit object name.

Sitaram Chamarty· Jul 4, 2015, 01:26 UTC · re: Junio C Hamano · lore

Re: git name-rev not accepting abbreviated SHA with --stdin

On 07/03/2015 11:06 PM, Junio C Hamano wrote:
Show 20 quoted lines
> Sitaram Chamarty <sitaramc@gmail.com> writes:
> 
>> On 06/25/2015 05:41 AM, Junio C Hamano wrote:
>>> Sitaram Chamarty <sitaramc@gmail.com> writes:
>>>
>>>> This *is* documented, but I'm curious why this distinction is made.
>>>
>>> I think it is from mere laziness, and also in a smaller degree
>>> coming from an expectation that --stdin would be fed by another
>>> script like rev-list where feeding full 40-hex is less work than
>>> feeding unique abbreviated prefix.
>>
>> Makes sense; thanks.  Maybe if I feel really adventurous I will,
>> one day, look at the code :-)
> 
> Sorry, but I suspect this is not 100% laziness; it is meant to read
> text that has object names sprinkled in and output text with object
> names substituted.  I suspect that this was done to prevent a short
> string that may look like an object name like deadbabe from getting
> converted into an unrelated commit object name.

As a perl programmer, laziness is much more palatable to me as a reason ;-)

Jokes apart, I'm not sure the chances of *both* those things happening -- an accidental hash-like string in the text *and* it matching an existing hash -- are high enough to bother. If it can be done without too much code, it probably should.

Junio C Hamano· Jul 4, 2015, 02:03 UTC · re: Sitaram Chamarty · lore

Re: git name-rev not accepting abbreviated SHA with --stdin

On Fri, Jul 3, 2015 at 6:26 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> Jokes apart, I'm not sure the chances of *both* those things happening
> -- an accidental hash-like string in the text *and* it matching an
> existing hash -- are high enough to bother.  If it can be done without
> too much code, it probably should.

To be fair to the original implementor, I think we didn't have an API to ask "do we have a committish object with this name?" with an abbreviated SHA-1. All we had was "do we have an object with this name?".

As the only answer the command can give is an exteneded SHA-1 for committish, it is understandable that hitting blobs and trees (which typically are much more numerous than committishes) with false positives would have been a real risk the implementation wanted to avoid.

← back to recent threads