From: Jeff King <peff@peff.net>
To: Elijah Newren <newren@gmail.com>
Cc: "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>,
"Bagas Sanjaya" <bagasdotme@gmail.com>,
"Eric Sunshine" <sunshine@sunshineco.com>,
"Derrick Stolee" <stolee@gmail.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v2 3/4] doc: document the special handling of -l0
Date: Wed, 14 Jul 2021 13:33:48 -0400 [thread overview]
Message-ID: <YO8f/A8qnTEDlnAr@coredump.intra.peff.net> (raw)
In-Reply-To: <CABPp-BFu4-SJrGbeSQTum_JOq4PHAGwGPPLQA+sHZMP4wvqA1w@mail.gmail.com>
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.
> > 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
next prev parent reply other threads:[~2021-07-14 17:33 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-11 0:46 [PATCH 0/3] Improve the documentation and warnings dealing with rename/copy limits Elijah Newren via GitGitGadget
2021-07-11 0:46 ` [PATCH 1/3] doc: clarify documentation for " Elijah Newren via GitGitGadget
2021-07-11 4:37 ` Bagas Sanjaya
2021-07-11 4:52 ` Elijah Newren
2021-07-12 15:03 ` Derrick Stolee
2021-07-12 21:27 ` Junio C Hamano
2021-07-11 0:46 ` [PATCH 2/3] doc: document the special handling of -l0 Elijah Newren via GitGitGadget
2021-07-11 4:54 ` Eric Sunshine
2021-07-11 4:54 ` Elijah Newren
2021-07-11 0:46 ` [PATCH 3/3] diff: correct warning message when renameLimit exceeded Elijah Newren via GitGitGadget
2021-07-12 15:09 ` Derrick Stolee
2021-07-12 18:13 ` Elijah Newren
2021-07-14 0:47 ` Junio C Hamano
2021-07-14 1:06 ` Elijah Newren
2021-07-14 1:10 ` Junio C Hamano
2021-07-14 1:22 ` Elijah Newren
2021-07-14 5:17 ` Junio C Hamano
2021-07-14 15:09 ` Elijah Newren
2021-07-14 1:12 ` [PATCH v2 0/4] Rename/copy limits -- docs, warnings, and new defaults Elijah Newren via GitGitGadget
2021-07-14 1:12 ` [PATCH v2 1/4] diff: correct warning message when renameLimit exceeded Elijah Newren via GitGitGadget
2021-07-14 1:12 ` [PATCH v2 2/4] doc: clarify documentation for rename/copy limits Elijah Newren via GitGitGadget
2021-07-14 7:37 ` Ævar Arnfjörð Bjarmason
2021-07-14 16:30 ` Elijah Newren
2021-07-14 22:08 ` Ævar Arnfjörð Bjarmason
2021-07-14 22:56 ` Elijah Newren
2021-07-14 1:12 ` [PATCH v2 3/4] doc: document the special handling of -l0 Elijah Newren via GitGitGadget
2021-07-14 16:45 ` Jeff King
2021-07-14 17:17 ` Elijah Newren
2021-07-14 17:33 ` Jeff King [this message]
2021-07-14 19:32 ` Elijah Newren
2021-07-14 1:12 ` [PATCH v2 4/4] Bump rename limit defaults (yet again) Elijah Newren via GitGitGadget
2021-07-14 16:43 ` Jeff King
2021-07-14 17:32 ` Elijah Newren
2021-07-14 17:57 ` Jeff King
2021-07-14 20:03 ` Elijah Newren
2021-07-14 20:47 ` Jeff King
2021-07-15 0:45 ` [PATCH v3 0/4] Rename/copy limits -- docs, warnings, and new defaults Elijah Newren via GitGitGadget
2021-07-15 0:45 ` [PATCH v3 1/4] diff: correct warning message when renameLimit exceeded Elijah Newren via GitGitGadget
2021-07-15 0:45 ` [PATCH v3 2/4] doc: clarify documentation for rename/copy limits Elijah Newren via GitGitGadget
2021-07-15 0:45 ` [PATCH v3 3/4] diffcore-rename: treat a rename_limit of 0 as unlimited Elijah Newren via GitGitGadget
2021-07-15 23:17 ` Junio C Hamano
2021-07-15 0:45 ` [PATCH v3 4/4] Bump rename limit defaults (yet again) Elijah Newren via GitGitGadget
2021-07-15 13:36 ` [PATCH v3 0/4] Rename/copy limits -- docs, warnings, and new defaults Derrick Stolee
2021-07-15 23:20 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YO8f/A8qnTEDlnAr@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=bagasdotme@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=newren@gmail.com \
--cc=stolee@gmail.com \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).