On Wed, Jul 14, 2021 at 01:12:32AM +0000, Elijah Newren via GitGitGadget wrote: > From: Elijah Newren <newren@xxxxxxxxx> > > As noted in commit 89973554b52c (diffcore-rename: make diff-tree -l0 > mean -l<large>, 2017-11-29), -l0 has had a magical special "large" > historical value associated with it. Document this value, particularly > since it is not large enough for some uses -- see commit 9f7e4bfa3b6d > (diff: remove silent clamp of renameLimit, 2017-11-13). > > Signed-off-by: Elijah Newren <newren@xxxxxxxxx> > --- > Documentation/diff-options.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt > index 11e08c3fd36..ba40ac66cc9 100644 > --- a/Documentation/diff-options.txt > +++ b/Documentation/diff-options.txt > @@ -594,6 +594,9 @@ of a delete/create pair. > exhaustive portion of rename/copy detection from running if > the number of rename/copy targets exceeds the specified > number. Defaults to diff.renameLimit. > ++ > +Note that for backward compatibility reasons, a value of 0 is treated > +the same as if a large value was passed (currently, 32767). Given the confusion around what "32767" even means to users, I wonder if we could just say: a value of 0 removes any artificial limits (but Git still has some internal limits which real-world cases are not likely to hit). Removing limits is after all the point of "0". I'm also not sure if it is simply for backwards compatibility. We commonly let "0" or "-1" mean "no limit" for convenience. It seems like something we'd want to support. -Peff