[PATCH on en/rename-progress] diffcore-rename: make diff-tree -l0 mean -l<large>

[PATCH on en/rename-progress] diffcore-rename: make diff-tree -l0 mean -l<large>

[Jonathan Tan]

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.
---
 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
-- 
2.15.0.173.g9268cf4a2.dirty

Re: [PATCH on en/rename-progress] diffcore-rename: make diff-tree -l0 mean -l<large>

[Elijah Newren]

On Wed, Nov 29, 2017 at 10:32 AM, Jonathan Tan <jonathantanmy@google.com> wrote:
> 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.

Re: [PATCH on en/rename-progress] diffcore-rename: make diff-tree -l0 mean -l<large>

[Jonathan Tan]

On Wed, 29 Nov 2017 10:51:20 -0800
Elijah Newren <newren@gmail.com> wrote:

> 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).

Ah...yes, you're right. I'll update the commit message if I need to send
out a new version or if Junio requests it (so that it's easier for him
to merge it in).

> Other than that minor issue, patch and test looks good to me.

Thanks.

Re: [PATCH on en/rename-progress] diffcore-rename: make diff-tree -l0 mean -l<large>

[Jonathan Nieder]

Elijah Newren wrote:
> On Wed, Nov 29, 2017 at 10:32 AM, Jonathan Tan <jonathantanmy@google.com> wrote:

>> 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

I think in the parenthesis you mean 'to allow "-l0" to suppress rename
detection', since this patch is all about allowing '-l0' already.

>> 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.

Thanks, both.  Looking at that patch, the fix is obviously correct.

With Elijah's commit message tweak,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

[PATCH on en/rename-progress v2] diffcore-rename: make diff-tree -l0 mean -l<large>

[Jonathan Tan]

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(+)

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
-- 
2.15.0.173.g9268cf4a2.dirty

Re: [PATCH on en/rename-progress v2] diffcore-rename: make diff-tree -l0 mean -l<large>

[Jonathan Nieder]

Jonathan Tan wrote:

> 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(+)

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

Thanks again.

> 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

Re: [PATCH on en/rename-progress v2] diffcore-rename: make diff-tree -l0 mean -l<large>

[Elijah Newren]

On Wed, Nov 29, 2017 at 12:11 PM, Jonathan Tan <jonathantanmy@google.com> wrote:
> 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(+)

Reviewed-by: Elijah Newren <newren@gmail.com>

Thanks.