On 4/20/2018 1:02 PM, Elijah Newren wrote:
On Fri, Apr 20, 2018 at 6:36 AM, Ben Peart <ben.pe...@microsoft.com> wrote:
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -37,6 +37,11 @@ merge.renameLimit::
during a merge; if not specified, defaults to the value of
diff.renameLimit.
+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.
Yes, but that requires people to know they need to do that and then
remember to pass it on the command line every time. We've found that
doesn't typically happen, we just get someone complaining about slow
merges. :)
That is why we added them as config options which change the default.
That way we can then set them on the repo and the default behavior gives
them better performance. They can still always override the config
setting with the command line options.
I think the documentation should mention that
"false" is the same as passing -Xno-renames, and "true" is the same as
passing -Xfind-renames. However, find-renames does take similarity
threshold as a parameter, so there's a question whether this option
should provide some way to do the same. I'm not sure the answer to
that; it may be that we'd want a separate config option for that, and
we can wait to add it until someone actually wants it.
I'm of the opinion that we shouldn't bother adding features that we
aren't sure someone will want/use. If it comes up, we can certainly add
it at a later date.
merge.renormalize::
Tell Git that canonical representation of files in the
repository has changed over time (e.g. earlier commits record
diff --git a/merge-recursive.c b/merge-recursive.c
index 9c05eb7f70..cd5367e890 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -3256,6 +3256,7 @@ static void merge_recursive_config(struct merge_options
*o)
git_config_get_int("merge.verbosity", &o->verbosity);
git_config_get_int("diff.renamelimit", &o->diff_rename_limit);
git_config_get_int("merge.renamelimit", &o->merge_rename_limit);
+ git_config_get_bool("merge.renames", &o->detect_rename);
git_config(git_xmerge_config, NULL);
}
I would expect an explicitly passed -Xno-renames or -Xfind-renames to
override the config setting. Could you check if that's the case?
Yes, command line options override the config settings. You can see
that in the code where the call to init_merge_options() which loads the
config settings is followed by parse_merge_opt() which loads the command
line options. I've also verified the behavior in the debugger (it's on
by default in the code, the config setting turns it off, then the
command line option turns it back on).
Also, if someone sets merge.renameLimit (to anything) and sets
merge.renames to false, then they've got a contradictory setup. Does
it make sense to check and warn about that anywhere?
I don't think we need to. The merge.renameLimit is only used if
detect_rename it turned on no matter how that gets turned on (default,
config setting, command line option) so there isn't really a change in
behavior here.
