{"thread":{"id":"39706","subject":"git name-rev not accepting abbreviated SHA with --stdin","startedAt":"2015-06-24T03:29:09Z","lastAt":"2015-07-04T02:03:21Z","messageCount":6,"participants":["Sitaram Chamarty","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"264700","messageId":"558A2405.2090709@gmail.com","threadId":"39706","inReplyTo":null,"subject":"git name-rev not accepting abbreviated SHA with --stdin","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2015-06-24T03:29:09Z","receivedAt":"2015-06-24T03:29:09Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"Hi all,\n\n\"git name-rev\" does not accept abbreviated SHAs if --stdin is used,\nthough it works when the SHA is given directly on the command line:\n\n $ git version\n git version 2.4.3\n $ git name-rev --tags d73f544\n d73f544 tags/v3.6.3~29\n $ git name-rev --tags --stdin <<< d73f544\n d73f544\n\nThis *is* documented, but I'm curious why this distinction is made. Is\nit merely a matter of parsing or were there some other complications I\nam unaware of, which forced this distinction to be made?\n\nthanks\nsitaram\n"},{"id":"264801","messageId":"xmqqsi9g8x51.fsf@gitster.dls.corp.google.com","threadId":"39706","inReplyTo":"558A2405.2090709@gmail.com","subject":"Re: git name-rev not accepting abbreviated SHA with --stdin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-06-25T00:11:38Z","receivedAt":"2015-06-25T00:11:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sitaram Chamarty writes:\n\n> This *is* documented, but I'm curious why this distinction is made.\n\nI think it is from mere laziness, and also in a smaller degree\ncoming from an expectation that --stdin would be fed by another\nscript like rev-list where feeding full 40-hex is less work than\nfeeding unique abbreviated prefix.\n"},{"id":"264805","messageId":"558B60E4.9020604@gmail.com","threadId":"39706","inReplyTo":"xmqqsi9g8x51.fsf@gitster.dls.corp.google.com","subject":"Re: git name-rev not accepting abbreviated SHA with --stdin","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2015-06-25T02:01:08Z","receivedAt":"2015-06-25T02:01:08Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 06/25/2015 05:41 AM, Junio C Hamano wrote:\n> Sitaram Chamarty writes:\n> \n>> This *is* documented, but I'm curious why this distinction is made.\n> \n> I think it is from mere laziness, and also in a smaller degree\n> coming from an expectation that --stdin would be fed by another\n> script like rev-list where feeding full 40-hex is less work than\n> feeding unique abbreviated prefix.\n\nMakes sense; thanks. Maybe if I feel really adventurous I will,\none day, look at the code :-)\n"},{"id":"265466","messageId":"xmqqbnft5eja.fsf@gitster.dls.corp.google.com","threadId":"39706","inReplyTo":"558B60E4.9020604@gmail.com","subject":"Re: git name-rev not accepting abbreviated SHA with --stdin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-03T17:36:41Z","receivedAt":"2015-07-03T17:36:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sitaram Chamarty writes:\n\n> On 06/25/2015 05:41 AM, Junio C Hamano wrote:\n>> Sitaram Chamarty writes:\n>> \n>>> This *is* documented, but I'm curious why this distinction is made.\n>> \n>> I think it is from mere laziness, and also in a smaller degree\n>> coming from an expectation that --stdin would be fed by another\n>> script like rev-list where feeding full 40-hex is less work than\n>> feeding unique abbreviated prefix.\n>\n> Makes sense; thanks. Maybe if I feel really adventurous I will,\n> one day, look at the code :-)\n\nSorry, but I suspect this is not 100% laziness; it is meant to read\ntext that has object names sprinkled in and output text with object\nnames substituted. I suspect that this was done to prevent a short\nstring that may look like an object name like deadbabe from getting\nconverted into an unrelated commit object name.\n"},{"id":"265508","messageId":"5597365E.7070508@gmail.com","threadId":"39706","inReplyTo":"xmqqbnft5eja.fsf@gitster.dls.corp.google.com","subject":"Re: git name-rev not accepting abbreviated SHA with --stdin","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2015-07-04T01:26:54Z","receivedAt":"2015-07-04T01:26:54Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 07/03/2015 11:06 PM, Junio C Hamano wrote:\n> Sitaram Chamarty writes:\n> \n>> On 06/25/2015 05:41 AM, Junio C Hamano wrote:\n>>> Sitaram Chamarty writes:\n>>>\n>>>> This *is* documented, but I'm curious why this distinction is made.\n>>>\n>>> I think it is from mere laziness, and also in a smaller degree\n>>> coming from an expectation that --stdin would be fed by another\n>>> script like rev-list where feeding full 40-hex is less work than\n>>> feeding unique abbreviated prefix.\n>>\n>> Makes sense; thanks. Maybe if I feel really adventurous I will,\n>> one day, look at the code :-)\n> \n> Sorry, but I suspect this is not 100% laziness; it is meant to read\n> text that has object names sprinkled in and output text with object\n> names substituted. I suspect that this was done to prevent a short\n> string that may look like an object name like deadbabe from getting\n> converted into an unrelated commit object name.\n\nAs a perl programmer, laziness is much more palatable to me as a reason\n;-)\n\nJokes apart, I'm not sure the chances of *both* those things happening\n-- an accidental hash-like string in the text *and* it matching an\nexisting hash -- are high enough to bother. If it can be done without\ntoo much code, it probably should.\n"},{"id":"265509","messageId":"CAPc5daVFRuBsZEZO=y5hY=ErQf7uy36Ejw2CLb3s8N5y6+T_ww@mail.gmail.com","threadId":"39706","inReplyTo":"5597365E.7070508@gmail.com","subject":"Re: git name-rev not accepting abbreviated SHA with --stdin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-04T02:03:21Z","receivedAt":"2015-07-04T02:03:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Fri, Jul 3, 2015 at 6:26 PM, Sitaram Chamarty wrote:\n> Jokes apart, I'm not sure the chances of *both* those things happening\n> -- an accidental hash-like string in the text *and* it matching an\n> existing hash -- are high enough to bother. If it can be done without\n> too much code, it probably should.\n\nTo be fair to the original implementor, I think we didn't have an API to ask\n\"do we have a committish object with this name?\" with an abbreviated SHA-1.\nAll we had was \"do we have an object with this name?\".\n\nAs the only answer the command can give is an exteneded SHA-1 for\ncommittish, it is understandable that hitting blobs and trees (which typically\nare much more numerous than committishes) with false positives would have\nbeen a real risk the implementation wanted to avoid.\n"}]}