Thread (35 messages) 35 messages, 7 authors, 2021-07-15

Re: [PATCH v2 3/4] doc: document the special handling of -l0

From: Elijah Newren <hidden>
Date: 2021-07-14 19:33:06

On Wed, Jul 14, 2021 at 10:33 AM Jeff King [off-list ref] wrote:
On Wed, Jul 14, 2021 at 10:17:21AM -0700, Elijah Newren wrote:
quoted
quoted
quoted
+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).
32767 is not an internal limit; and as such, it is absolutely an
artificial limit.  I had to use 48941 just a few years ago, and that
value (and others larger than 32767) are fully supported.
OK, I thought there was still some 32-bit m*n limits, but I guess not.
There was once upon a time, but not since 9f7e4bfa3b6d (diff: remove
silent clamp of renameLimit, 2017-11-13).
quoted
quoted
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.
Making 0 mean unlimited could be done, and I think it'd be a one-line
change, but that's not what commit 89973554b52c (diffcore-rename: make
diff-tree -l0 mean -l<large>, 2017-11-29) tried to do.

I'm not opposed to such a change in the meaning of "0", but I am
opposed to documenting this value as unlimited unless we make it so.
Thanks for clarifying. It does seem silly that "0" means "big, but kind
of arbitrary". But I'm OK to punt on that change for now (and in the
meantime, I have no real opinion on whether or how to document the
current behavior).

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help