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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 10, 2022, 19:57 UTC
Message-ID: <xmqqtuc5d1hp.fsf@gitster.g>
In-Reply-To: <xmqqv8wlejgc.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 14 quoted lines

> Neeraj Singh <nksingh85@gmail.com> 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.