Junio C Hamano <gitster@xxxxxxxxx> writes: > Neeraj Singh <nksingh85@xxxxxxxxx> 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.
