Re: [PATCH on en/rename-progress] diffcore-rename: make diff-tree -l0 mean -l<large>
- From
Elijah Newren <newren@gmail.com>
- Date
- Nov 29, 2017, 18:51 UTC
- Message-ID
- <CABPp-BHEyXcjFzGvLHToz+2FRMM3g-mUTxn2uf8exQV61qff9w@mail.gmail.com>
- In-Reply-To
- <20171129183200.178183-1-jonathantanmy@google.com>
On Wed, Nov 29, 2017 at 10:32 AM, Jonathan Tan <jonathantanmy@google.com> wrote:
Show 22 quoted lines
> 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.