Elijah Newren <new...@gmail.com> writes: >>>> +merge.renames:: >>>> + Whether and how Git detects renames. If set to "false", >>>> + rename detection is disabled. If set to "true", basic rename >>>> + detection is enabled. This is the default. >>> >>> >>> One can already control o->detect_rename via the -Xno-renames and >>> -Xfind-renames options. > ... > Sorry, I think I wasn't being clear. The documentation for the config > options for e.g. diff.renameLimit, fetch.prune, log.abbrevCommit, and > merge.ff all mention the equivalent command line parameters. Your > patch doesn't do that for merge.renames, but I think it would be > helpful if it did.
Yes, and if we are adding a new configuration, we should do so in such a way that we do not have to come back and extend it when we know what the command line option does and the configuration being proposed is less capable already. I wonder if we can just add a single configuration whose value can be "never" to pretend as if "--Xno-renames" were given, and some similarity score like "50" to pretend as if "--Xfind-renames=50" were given. That is, merge.renames does not have to a simple "yes-no to control the --Xno-renames option". And it would of course be better to document it. I also had to wonder how "merge -s resolve" faired, if the project is not interested in renamed paths at all. Thanks.
