Subject: Re: [PATCH v5 3/5] core.fsync: introduce granular fsync control

From: Junio C Hamano <[email-masked]>
Date: Thu, 10 Mar 2022 11:57:38 -0800

Junio C Hamano <[email-masked]> writes:

> Neeraj Singh <[email-masked]> writes:
>
>>> > At the conclusion of this series, I defined 'default' as an aggregate
>>> > option that includes
>>> > the platform default.  I'd prefer not to have any statefulness of the
>>> > core.fsync setting so
>>> > that there is less confusion about the final fsync configuration.
>>>
>>> Then scratch your preference ;-)
>>
>> Just to clarify, linguistically, by 'scratch' do you mean that I should drop
>> my preference
>
> Yes.

Let me take this part back.

I do not mind too deeply if this were "each occurrence of core.fsync
as a whole replaces whatever we saw earlier, i.e. last-one-wins".

But if we were going that route, instead of starting from an empty
set, I'd prefer to see it begin with the built-in default (i.e. the
one you defined to mimic the traditional behaviour before core.fsync
was introduced) and added or deleted by each (possibly '-' prefixed)
element on the comma-separated list, with an explicit way to clear
the built-in default.  E.g. "none,refs" would clear the components
traditionally fsync'ed by default and choose only "refs" component,
while "-pack-metadata" would mean the default ones minus
"pack-metadata" component are subject for fsync'ing.  An empty
string would naturally mean "By having this core.fsync entry, I am
telling you not to pay any attention to what lower-precedence
configuration files said.  But I want the built-in default, without
any additions or subtractions made by this entry, just the default,
please" in such a scheme, so do not forbid it.

Or, we can inherit from the previous configuration file to allow
/etc/gitconfig and the ones shipped by Git for Windows to augment
the built-in default before letting end-user configuration to
further customize the preference.

Either is fine by me.

Thanks.