Re: [PATCH v3 00/13] more miscellaneous Bloom filter improvements, redux

On Fri, Sep 18, 2020 at 09:31:40AM -0400, Taylor Blau wrote:

Junio,

Two replacements for this version, if it ends up being the one you
queue. Gàbor suggested some helpful changes on 12/13, which in turn
cause a conflict when applying 13/13.

I should mention, the changes are purely an alteration to the new
documentation introduced by this series. Here's a range-diff:

12:  4549f0f747 ! 12:  1c3f6b5c96 builtin/commit-graph.c: introduce '--max-new-filters=<n>'
    @@ Documentation/git-commit-graph.txt: this option is given, future commit-graph wr
      +
     +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.
    ++enforced. Only commits present in the new layer count against this
    ++limit. To retroactively compute Bloom filters over earlier layers, it is
    ++advised to use `--split=replace`.
     ++
      With the `--split[=<strategy>]` option, write the commit-graph as a
      chain of multiple commit-graph files stored in
13:  375ecf1f36 ! 13:  a7330ee850 commit-graph: introduce 'commitGraph.maxNewFilters'
    @@ Documentation/config/commitgraph.txt
      	commit-graph file (if it exists, and they are present). Defaults to

      ## Documentation/git-commit-graph.txt ##
    -@@ Documentation/git-commit-graph.txt: data.
    - With the `--max-new-filters=<n>` option, generate at most `n` new Bloom
    +@@ Documentation/git-commit-graph.txt: 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.
    -+length zero Bloom filter. Overrides the `commitGraph.maxNewFilters`
    -+configuration.
    + enforced. Only commits present in the new layer count against this
    + limit. To retroactively compute Bloom filters over earlier layers, it is
    +-advised to use `--split=replace`.
    ++advised to use `--split=replace`. Overrides the
    ++`commitGraph.maxNewFilters` configuration.
      +
      With the `--split[=<strategy>]` option, write the commit-graph as a
      chain of multiple commit-graph files stored in

Thanks,
Taylor