On Wed, Jul 14, 2021 at 10:33 AM Jeff King <peff@xxxxxxxx> wrote: > > On Wed, Jul 14, 2021 at 10:17:21AM -0700, Elijah Newren wrote: > > > > > +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). > > > 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
