On 9/1/2020 3:43 AM, Eric Wong wrote:
> These allows users to write hash-agnostic scripts and configs to
> disable abbreviations. Using "-c core.abbrev=40" will be
> insufficient with SHA-256, and "-c core.abbrev=64" won't work
> with SHA-1 repos today.
>
> Signed-off-by: Eric Wong <e@xxxxxxxxx>
> ---
> I kinda wanted to allow a value of "max", but I figured the existing
> boolean falsiness words might make more sense with `--no-abbrev' in
> for some commands... Naming is hard :x
>
> config.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/config.c b/config.c
> index 2bdff4457b..f2e09c72ca 100644
> --- a/config.c
> +++ b/config.c
> @@ -1217,6 +1217,10 @@ static int git_default_core_config(const char *var, const char *value, void *cb)
> return config_error_nonbool(var);
> if (!strcasecmp(value, "auto"))
> default_abbrev = -1;
> + else if (!strcasecmp(value, "false") ||
> + !strcasecmp(value, "no") ||
> + !strcasecmp(value, "off"))
> + default_abbrev = the_hash_algo->hexsz;
I'm not sure we need three synonyms for "no-abbrev" here.
"false" would be natural, except I think in a few places
the config value "0" is also interpreted as "false", but
as seen below a value of "0" snaps up to the minimum
allowed abbreviation.
> else {
> int abbrev = git_config_int(var, value);
> if (abbrev < minimum_abbrev || abbrev > the_hash_algo->hexsz)
Perhaps "core.abbrev = never" would be a good option?
After we decide on the word, this patch needs:
* Updates to Documentation/config/core.txt
* A test that works with both hash versions.
Thanks,
-Stolee
