On 2020-09-01 at 15:49:55, Junio C Hamano wrote: > I was in the vicinity of this code recently for reviewing another > topic, but IIRC, 0 came from the UI level does get rounded up to the > minimum accepted and never reach "default_abbrev", but if you manage > to place 0 or -1 in default_abbrev here (e.g. with additional code, > like the above part with the right hand side of the assignment > updated), I think the value will propagate throughout the codepath > and causes the downstream code to do the right thing. 0 will give > you no-abbreviation (i.e. full length depending on the length of the > hash) and -1 will give you the "scale as appropriate for the size of > the object store". > > I have mild preference for using 0 over hardcoded single "full > length" here. Even though we currently do not plan to allow > multiple hashes in use simultaneously in a single invocation of Git, > if that ever happens, we will regret hardcoding the_hash_algo->hexsz > on the right hand side of the assignment here, like this patch does. I think we have some commands that accept --abbrev=0 as a value meaning "no abbreviation", because I've touched that code as part of the SHA-256 work. So as far as the option value is concerned, I think it may make sense to use 0 for that meaning and just document it. -- brian m. carlson: Houston, Texas, US
Attachment:
signature.asc
Description: PGP signature
