On Thu, Aug 8, 2019 at 12:00 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> writes: > > >> --- a/Documentation/config/merge.txt > >> +++ b/Documentation/config/merge.txt > >> @@ -54,7 +54,8 @@ merge.directoryRenames:: > >> moved into the new directory. If set to "conflict", a conflict > >> will be reported for such paths. If merge.renames is false, > >> merge.directoryRenames is ignored and treated as false. Defaults > >> - to "conflict". > >> + to "conflict" unless `feature.experimental` is enabled and the > >> + default is "true". > > > > I have a hard time parsing that changed sentence. Perhaps something like: > > ...unless `feature.experimental` is enabled in which case the > > default is "true". > > ? > > That reads better. :-) > But I am not sure about the wisdom of controlling between conflict > and true with this feature macro in the first place. > > Between "conflict" and "true", the former forces the end user to > verify (or allows the end user to veto) the auto resolution by the > heuristics and is always a safer if more cumbersome option. It's > not like blindly trusting the directory rename heuristics is the > bright future for all users, is it? I'm afraid I don't quite know what the intended usecase for feature.experimental is, and I'm unfamiliar with both pack.useSparse and fetch.negotiationAlgorithm for comparison. If the intended usecase is stuff that is expected to become the future for all users, then I agree with you; "conflict" is the right default for both now and in the future so feature.experimental should not change it. However, Stollee's commit message started with "The 'feature.experimental' setting includes config options that are not committed to become defaults". If these are settings that are "intended" but not "committed" to become defaults, then yes, you're absolutely right. (And in such a case, it might be nice to add that distinction to the commit message.) If there is some other purpose, it depends on what that purpose is.
