Re: [PATCH v3 0/8] commit-reach: terminate merge-base walk when one side is exhausted
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 26, 2026, 16:36 UTC
- Message-ID
- <xmqqjyrl8di0.fsf@gitster.g>
- In-Reply-To
- <pull.2149.v3.git.1782479286.gitgitgadget@gmail.com>
"Kristofer Karlsson via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 35 quoted lines
> Changes since v2:
>
> * New patch 8/8: moved the min_generation termination check and the
> last_gen monotonicity assertion into paint_queue_get(), consolidating
> halt conditions. commit_graph_generation() is now called once per
> dequeued commit and shared across all checks.
>
> * Widened the generation-monotonicity BUG assertion to fire
> unconditionally, not only when min_generation is set. The side-exhaustion
> optimization depends on correct generation ordering, so the assertion
> should always be active. This is a behavior change: the BUG() now fires
> for any generation ordering violation, regardless of the caller.
>
> * Moved all halt conditions inside paint_queue_get() with the "pop first"
> form: pop, check, then decrement counters. This keeps the optimization
> commit's diff minimal (just inserting the new checks between pop and
> decrement).
>
> * Shortened the doc comment on paint_queue_get() to describe what it does
> rather than how. Inline comments on each return NULL explain the specific
> halt condition.
>
> * Replaced the manual commit-graph setup in the step-count test with
> run_all_modes, which now sets GIT_TRACE2_EVENT per mode and produces
> trace-mode-{none,full,half,no-gdat}.txt files.
>
> * Added a test_paint_down_steps helper for concise 4-mode step assertions
> with diagnostic output on mismatch (prints "expected X, got Y" instead of
> a silent grep failure).
>
> * Added step-count assertions to the single-walk edge-case tests:
> in_merge_bases_many:self, pending-stale, infinity-both-sides,
> mixed-finite-infinity.
>
> * Included step counts alongside wall-clock times in the benchmark tables.I am getting this failure standalone, when applied on the same base as where v2 was applied earlier. For now I'll eject it from 'seen'.
expecting success of 6600.12 'get_merge_bases_many':
cat >input <<-\EOF &&
A:commit-5-7
X:commit-4-8
X:commit-6-6
X:commit-8-3
EOF
{
echo "get_merge_bases_many(A,X):" &&
git rev-parse commit-5-6 \
commit-4-7 | sort
} >expect &&
test_all_modes get_merge_bases_manyBUG: commit-reach.c:152: bad generation skip 9 > 8 at 772be737f220103f706a39013c0d115009feefec not ok 12 - get_merge_bases_many # # cat >input <<-\EOF && # A:commit-5-7 # X:commit-4-8