patchdiffcore-rename: make diff-tree -l0 mean -l<large>

> In the documentation of diff-tree, it is stated that the -l option
> "prevents rename/copy detection from running if the number of
> rename/copy targets exceeds the specified number". The documentation
> does not mention any special handling for the number 0, but the
> implementation before commit b520abf ("sequencer: warn when internal
> merge may be suboptimal due to renameLimit", 2017-11-14) treated 0 as a
> special value indicating that the rename limit is to be a very large
> number instead.
>
> The commit b520abf changed that behavior, treating 0 as 0. Revert this
> behavior to what it was previously. This allows existing scripts and
> tools that use "-l0" to continue working. The alternative (to allow
> "-l0") is probably much less useful, since users can just refrain from
> specifying -M and/or -C to have the same effect.
>
> Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
> ---
> Note that this patch is built on en/rename-progress.
>
> We noticed this through an automated test for an internal tool - the
> tool uses git diff-tree with -l0, and no longer produces the same
> results as before.

> Thanks for testing that version and sending along the fix.
> 
> I suspect the commit referenced twice in the commit message should
> have been 9f7e4bfa3b ("diff: remove silent clamp of renameLimit",
> 2017-11-13) rather than b520abf ("sequencer: warn when internal merge
> may be suboptimal due to renameLimit", 2017-11-14).

>> In the documentation of diff-tree, it is stated that the -l option
>> "prevents rename/copy detection from running if the number of
>> rename/copy targets exceeds the specified number". The documentation
>> does not mention any special handling for the number 0, but the
>> implementation before commit b520abf ("sequencer: warn when internal
>> merge may be suboptimal due to renameLimit", 2017-11-14) treated 0 as a
>> special value indicating that the rename limit is to be a very large
>> number instead.
>>
>> The commit b520abf changed that behavior, treating 0 as 0. Revert this
>> behavior to what it was previously. This allows existing scripts and
>> tools that use "-l0" to continue working. The alternative (to allow
>> "-l0") is probably much less useful, since users can just refrain from

>> specifying -M and/or -C to have the same effect.
>>
>> Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
>> ---
>> Note that this patch is built on en/rename-progress.
>>
>> We noticed this through an automated test for an internal tool - the
>> tool uses git diff-tree with -l0, and no longer produces the same
>> results as before.
>
> Thanks for testing that version and sending along the fix.
>
> I suspect the commit referenced twice in the commit message should
> have been 9f7e4bfa3b ("diff: remove silent clamp of renameLimit",
> 2017-11-13) rather than b520abf ("sequencer: warn when internal merge
> may be suboptimal due to renameLimit", 2017-11-14).
>
> Other than that minor issue, patch and test looks good to me.

> In the documentation of diff-tree, it is stated that the -l option
> "prevents rename/copy detection from running if the number of
> rename/copy targets exceeds the specified number". The documentation
> does not mention any special handling for the number 0, but the
> implementation before commit 9f7e4bfa3b ("diff: remove silent clamp of
> renameLimit", 2017-11-13) treated 0 as a special value indicating that
> the rename limit is to be a very large number instead.
>
> The commit 9f7e4bfa3b changed that behavior, treating 0 as 0. Revert
> this behavior to what it was previously. This allows existing scripts
> and tools that use "-l0" to continue working. The alternative (to have
> "-l0" suppress rename detection) is probably much less useful, since
> users can just refrain from specifying -M and/or -C to have the same
> effect.
>
> Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
> ---
> v2 is exactly the same as previously, except that the commit message is
> changed following Elijah Newren's and Jonathan Nieder's comments.
>
>  diffcore-rename.c      |  2 ++
>  t/t4001-diff-rename.sh | 15 +++++++++++++++
>  2 files changed, 17 insertions(+)

> diff --git a/diffcore-rename.c b/diffcore-rename.c
> index 9ca0eaec7..245e999fe 100644
> --- a/diffcore-rename.c
> +++ b/diffcore-rename.c
> @@ -392,6 +392,8 @@ static int too_many_rename_candidates(int num_create,
>  	 *
>  	 *    num_create * num_src > rename_limit * rename_limit
>  	 */
> +	if (rename_limit <= 0)
> +		rename_limit = 32767;
>  	if ((num_create <= rename_limit || num_src <= rename_limit) &&
>  	    ((uint64_t)num_create * (uint64_t)num_src
>  	     <= (uint64_t)rename_limit * (uint64_t)rename_limit))
> diff --git a/t/t4001-diff-rename.sh b/t/t4001-diff-rename.sh
> index 0d1fa45d2..eadf4f624 100755
> --- a/t/t4001-diff-rename.sh
> +++ b/t/t4001-diff-rename.sh
> @@ -230,4 +230,19 @@ test_expect_success 'rename pretty print common prefix and suffix overlap' '
>  	test_i18ngrep " d/f/{ => f}/e " output
>  '
>  
> +test_expect_success 'diff-tree -l0 defaults to a big rename limit, not zero' '
> +	test_write_lines line1 line2 line3 >myfile &&
> +	git add myfile &&
> +	git commit -m x &&
> +
> +	test_write_lines line1 line2 line4 >myotherfile &&
> +	git rm myfile &&
> +	git add myotherfile &&
> +	git commit -m x &&
> +
> +	git diff-tree -M -l0 HEAD HEAD^ >actual &&
> +	# Verify that a rename from myotherfile to myfile was detected
> +	grep "myotherfile.*myfile" actual
> +'
> +
>  test_done

> In the documentation of diff-tree, it is stated that the -l option
> "prevents rename/copy detection from running if the number of
> rename/copy targets exceeds the specified number". The documentation
> does not mention any special handling for the number 0, but the
> implementation before commit 9f7e4bfa3b ("diff: remove silent clamp of
> renameLimit", 2017-11-13) treated 0 as a special value indicating that
> the rename limit is to be a very large number instead.
>
> The commit 9f7e4bfa3b changed that behavior, treating 0 as 0. Revert
> this behavior to what it was previously. This allows existing scripts
> and tools that use "-l0" to continue working. The alternative (to have
> "-l0" suppress rename detection) is probably much less useful, since
> users can just refrain from specifying -M and/or -C to have the same
> effect.
>
> Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
> ---
> There are multiple issues with the commit message, so I am sending this
> new version out.
>
> v2 is exactly the same as previously, except that the commit message is
> changed following Elijah Newren's and Jonathan Nieder's comments.
> ---
>  diffcore-rename.c      |  2 ++
>  t/t4001-diff-rename.sh | 15 +++++++++++++++
>  2 files changed, 17 insertions(+)