Ben Peart <[email protected]> writes:
> diff.renameLimit::
> The number of files to consider when performing the copy/rename
> - detection; equivalent to the 'git diff' option `-l`.
> + detection; equivalent to the 'git diff' option `-l`. This setting
> + has no effect if rename detection is turned off.
You mean "turned off via diff.renames"?
This is not meant as a suggestion to rewrite this paragraph
further---but if the answer is "no", then that might be an
indication that the sentence is inviting a misunderstanding.
> diff.renames::
> Whether and how Git detects renames. If set to "false",
> diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
> index 5a9ab969db..38492bcb98 100644
> --- a/Documentation/merge-config.txt
> +++ b/Documentation/merge-config.txt
> @@ -39,7 +39,8 @@ include::fmt-merge-msg-config.txt[]
> merge.renameLimit::
> The number of files to consider when performing rename detection
> during a merge; if not specified, defaults to the value of
> - diff.renameLimit.
> + diff.renameLimit. This setting has no effect if rename detection
> + is turned off.
Ditto. If your design is to make the merge machinery completely
ignore diff.renames and only pay attention to merge.renames [*1*],
then it probably is a good idea to be more specific here, by saying
"... is turned off via ...", though.
> merge.renames::
> Whether and how Git detects renames. If set to "false",
[Footnote]
*1* ...which I do not think is such a good idea, by the way. I'd
personally expect merge.renames to allow overriding and falling back
to diff.renames, just like the {merge,diff}.renameLimit pair does.
