Sitaram Chamarty [off-list ref] writes:
On 06/25/2015 05:41 AM, Junio C Hamano wrote:
quoted
Sitaram Chamarty [off-list ref] writes:
quoted
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.
On 07/03/2015 11:06 PM, Junio C Hamano wrote:
Sitaram Chamarty [off-list ref] writes:
quoted
On 06/25/2015 05:41 AM, Junio C Hamano wrote:
quoted
Sitaram Chamarty [off-list ref] writes:
quoted
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.
On Fri, Jul 3, 2015 at 6:26 PM, Sitaram Chamarty [off-list ref] 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.