Re: [PATCH 10/10] lower core.maxTreeDepth default to 2048

From: Jeff King <peff@peff.net>
Date: Aug 31, 2023, 22:31 UTC
Message-ID: <20230831223109.GA952036@coredump.intra.peff.net>
In-Reply-To: <096e01d9dc56$6d9f12a0$48dd37e0$@nexbridge.com>

On Thu, Aug 31, 2023 at 05:59:28PM -0400, rsbecker@nexbridge.com wrote:

Show 12 quoted lines

> I have been trying to figure out the implications of this and went down the
> wrong rabbit hole. Are we taking about the tree depth of the underlying
> Merkel Tree (no) or the tree-ish thing representing the file system
> (apparently yes). In this case, a practical depth of 2048 hits the exact max
> path size on the NonStop platform, so I have no issue there. My concern is
> one of terminology. My assumption of what maxTreeDepth meant, from other
> terminology used in git, seemed (wrongly) to align with the use of --depth=n
> where n<maxTreeDepth parameters for commands like fetch. From a user
> intuition (arguably, if I have any here) is that the parameter should be
> more of a path nomenclature, like maxPathHeight or maxHierarchyHeight rather
> than what is currently in flight. Just my opinion and I'm fine no matter
> which way.

The documentation from the patch is:

  +core.maxTreeDepth::
  +       The maximum depth Git is willing to recurse while traversing a
  +       tree (e.g., "a/b/cde/f" has a depth of 4). This is a fail-safe
  +       to allow Git to abort cleanly, and should not generally need to
  +       be adjusted. The default is 4096.

Does reading that answer your question and make the meaning clear? If not, can you suggest any changes?

I'd like to stick with "depth" here as it's commonly used in other places to mean the same thing (e.g., git-grep's --max-depth option).

I also think this is something that most people will remain completely oblivious to, as you'd only hit it for absurd cases.

-Peff