On Thu, Mar 10, 2022 at 11:57 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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. Okay, I'll implement this version, since this is close to my preference. Under this schema, 'default' isn't useful as an aggregate option, so I'll eliminate that.
