On 8/8/2019 2:59 PM, Junio C Hamano 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 would not set rerere.autoUpdate to true when feature.experimental > is set; for exactly the same reason, I do not find it reasonable to > set this to true with feature.experimental macro. OK. I can remove it from the feature.experimental variable. Shall I keep the enum logic and the use of repo-settings.c? I can split them out into a separate patch. -Stolee
