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