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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 18, 2020, 17:43 UTC
Message-ID: <xmqqft7fm14b.fsf@gitster.c.googlers.com>
In-Reply-To: <20200918132937.GA1601745@nand.local>

Taylor Blau <me@ttaylorr.com> writes:

Show 9 quoted lines

> 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/cover.1600397826.git.me@ttaylorr.com/

I think you meant <20200918132727.GB1600256@nand.local> 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.