Re: [PATCH 12/12] builtin/commit-graph.c: introduce '--max-new-filters=<n>'
From: Jeff King <hidden>
Date: 2020-09-11 17:52:20
On Wed, Sep 09, 2020 at 11:24:00AM -0400, Taylor Blau wrote:
quoted hunk ↗ jump to hunk
diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-commit-graph.txt index 17405c73a9..81a2e65903 100644 --- a/Documentation/git-commit-graph.txt +++ b/Documentation/git-commit-graph.txt@@ -67,6 +67,12 @@ this option is given, future commit-graph writes will automatically assume that this option was intended. Use `--no-changed-paths` to stop storing this data. + +With the `--max-new-filters=<n>` option, generate at most `n` new Bloom +filters (if `--changed-paths` is specified). If `n` is `-1`, no limit is +enforced. Commits whose filters are not calculated are stored as a +length zero Bloom filter, and their bit is marked in the `BFXL` chunk. +Overrides the `commitGraph.maxNewFilters` configuration.
The BFXL chunk doesn't exist anymore in this iteration, right? I wondered about having a user-facing "-1" here. My gut feeling is that we usually use "0" to mean "no limit" in other places, and it probably make sense to be consistent. It does look like we use both, though, and I'm having trouble formulating a grep pattern to find examples that doesn't produce a lot of noise. These are "0 is no limit": pack.windowMemory pack.deltaCacheSize git-daemon --max-connections These are "-1 is no limit": git-grep --max-depth rev-list --max-parents (I think?) So I dunno. It's a pretty minor thing, but I think it's good to aim for consistency, and since this is user-facing we won't be able to change it later. -Peff