Subject: Re: [PATCH v3 13/13] commit-graph: introduce 'commitGraph.maxNewFilters'

From: Junio C Hamano <[email-masked]>
Date: Fri, 18 Sep 2020 10:43:48 -0700

Taylor Blau <[email-masked]> writes:

> On Thu, Sep 17, 2020 at 10:59:57PM -0400, Taylor Blau wrote:
>> Introduce a configuration variable to specify a default value for the
>> recently-introduce '--max-new-filters' option of 'git commit-graph
>> write'.
>
> The replacement in [1] causes a conflict when applying this patch after
> it, so here is a suggested resolution:
>
> [1]: https://lore.kernel.org/git/[email-masked]/

I think you meant <[email-masked]> not the
cover letter.  Here is what I ended up with:

    $ git checkout tb/bloom-improvements
    $ git diff @{yesterday}
    diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-commit-graph.txt
    index 60df4e4bfa..de6b6de230 100644
    --- a/Documentation/git-commit-graph.txt
    +++ b/Documentation/git-commit-graph.txt
    @@ -69,8 +69,9 @@ 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. Overrides the `commitGraph.maxNewFilters`
    +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`.  Overrides the `commitGraph.maxNewFilters`
     configuration.
     +
     With the `--split[=<strategy>]` option, write the commit-graph as a

Thanks.