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

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

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.

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.