Re: [PATCH v2 0/7] commit-reach: terminate merge-base walk when one side is exhausted

From: Derrick Stolee <stolee@gmail.com>
Date: Jun 24, 2026, 13:34 UTC
Message-ID: <67c00a9f-2aa2-4e83-9c0a-317ca589b232@gmail.com>
In-Reply-To: <pull.2149.v2.git.1782303254.gitgitgadget@gmail.com>

On 6/24/2026 8:14 AM, Kristofer Karlsson via GitGitGadget wrote:

Show 22 quoted lines

> Benchmarks
> 
> Step counts are deterministic (measured via trace2_data_intmax added in
> patch 4). Wall-clock times are medians over 10-20 runs with CPU governor set
> to performance.
> 
> 2.6M-commit monorepo with commit-graph (baseline v2.55.0-rc1):
> 
>                                         steps              wall-clock
> merge-base --all  (across import)    2682391 ->  53521     7.26s ->   88ms
> merge-base --all  (1000 apart)       2659607 ->   1106     6.98s ->    8ms
> merge-tree        (across import)          -               8.11s ->  100ms
> 
> 
> git.git (88k commits, commit-graph):
> 
>                                         steps              wall-clock
> merge-base --all v2.0.0 v2.55.0-rc1   72264 ->  44589      82ms ->   49ms
> merge-base --all HEAD HEAD~1000         9873 ->   3817      19ms ->    9ms
> merge-base --all HEAD HEAD~10000       72285 ->  41523      80ms ->   48ms
> merge-base HEAD HEAD~1000                  -                 9ms ->    9ms
> merge-base --is-ancestor HEAD~1000 HEAD    -                 6ms ->    6ms

I like seeing these updates including the deterministic steps. Is there a reason you don't include the step data for 'merge-tree (across import)' in your monorepo case? The wall-clock is substantial, so it's not like the last two examples in git.git where there may not be any difference.

Thanks, -Stolee