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

On my Linux system, all of our recursive tree walking algorithms can run up to the 4096 default limit without segfaulting. But not all platforms will have stack sizes as generous (nor might even Linux if we kick off a recursive walk within a thread).

In particular, several of the tests added in the previous few commits fail in our Windows CI environment. Through some guess-and-check pushing, I found that 3072 is still too much, but 2048 is OK.

These are obviously vague heuristics, and there is nothing to promise that another system might not have trouble at even lower values. But it seems unlikely anybody will be too angry about a 2048-depth limit (this is close to the default max-pathname limit on Linux even for a pathological path like "a/a/a/..."). So let's just lower it.

Some alternatives are:

  - configure separate defaults for Windows versus other platforms.

  - just skip the tests on Windows. This leaves Windows users with the
    annoying case that they can be crashed by running out of stack
    space, but there shouldn't be any security implications (they can't
    go deep enough to hit integer overflow problems).

Since the original default was arbitrary, it seems less confusing to just lower it, keeping behavior consistent across platforms.

Signed-off-by: Jeff King <peff@peff.net>
---
Arguably this could be squashed into patch 5. But I thought that
following the sequence of logic (from "4096 is probably OK" to "whoops,
it's not") had some value to share. AFAIK GitHub is still running with
the 4096 limit; I discovered the Windows issue only while preparing this
for upstream. But I still find it highly unlikely that somebody would
run into it in practice.

 environment.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)