# git name-rev not accepting abbreviated SHA with --stdin 6 messages from 2015-06-24 to 2015-07-04. Participants: Sitaram Chamarty, Junio C Hamano. Thread: https://gitlist.dev/t/39706 ## Sitaram Chamarty, 2015-06-24 03:29 Subject: git name-rev not accepting abbreviated SHA with --stdin Message-ID: <558A2405.2090709@gmail.com> URL: https://gitlist.dev/e/558A2405.2090709%40gmail.com ``` 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, 2015-06-25 00:11 Subject: Re: git name-rev not accepting abbreviated SHA with --stdin Message-ID: URL: https://gitlist.dev/e/xmqqsi9g8x51.fsf%40gitster.dls.corp.google.com In-Reply-To: <558A2405.2090709@gmail.com> ``` Sitaram Chamarty 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, 2015-06-25 02:01 Subject: Re: git name-rev not accepting abbreviated SHA with --stdin Message-ID: <558B60E4.9020604@gmail.com> URL: https://gitlist.dev/e/558B60E4.9020604%40gmail.com In-Reply-To: ``` On 06/25/2015 05:41 AM, Junio C Hamano wrote: > Sitaram Chamarty 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, 2015-07-03 17:36 Subject: Re: git name-rev not accepting abbreviated SHA with --stdin Message-ID: URL: https://gitlist.dev/e/xmqqbnft5eja.fsf%40gitster.dls.corp.google.com In-Reply-To: <558B60E4.9020604@gmail.com> ``` Sitaram Chamarty writes: > On 06/25/2015 05:41 AM, Junio C Hamano wrote: >> Sitaram Chamarty 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, 2015-07-04 01:26 Subject: Re: git name-rev not accepting abbreviated SHA with --stdin Message-ID: <5597365E.7070508@gmail.com> URL: https://gitlist.dev/e/5597365E.7070508%40gmail.com In-Reply-To: ``` On 07/03/2015 11:06 PM, Junio C Hamano wrote: > Sitaram Chamarty writes: > >> On 06/25/2015 05:41 AM, Junio C Hamano wrote: >>> Sitaram Chamarty 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, 2015-07-04 02:03 Subject: Re: git name-rev not accepting abbreviated SHA with --stdin Message-ID: URL: https://gitlist.dev/e/CAPc5daVFRuBsZEZO%3Dy5hY%3DErQf7uy36Ejw2CLb3s8N5y6%2BT_ww%40mail.gmail.com In-Reply-To: <5597365E.7070508@gmail.com> ``` On Fri, Jul 3, 2015 at 6:26 PM, Sitaram Chamarty 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. ```