From: "Kristofer Karlsson via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: Taylor Blau <me@ttaylorr.com>,
Kristofer Karlsson <krka@spotify.com>,
Patrick Steinhardt <ps@pks.im>,
Kristofer Karlsson <krka@spotify.com>
Subject: [PATCH v2 0/2] commit-graph: fix topo_levels slab propagation regression
Date: Thu, 09 Jul 2026 15:02:59 +0000 [thread overview]
Message-ID: <pull.2170.v2.git.1783609382.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.2170.git.1783418384.gitgitgadget@gmail.com>
When fetch.writeCommitGraph is enabled (or git maintenance runs after
fetch), an incremental commit-graph write computes generation numbers for
the newly added commits. For commits already in the graph, their topo levels
should be read from the existing layers, making the DFS proportional to the
number of new commits.
199d452758 (commit-graph: return the prepared commit graph from
prepare_commit_graph(), 2025-09-04), part of the ps/commit-graph-via-source
series [1], refactored the loop that propagates the topo_levels slab to each
layer of the commit-graph chain. The original code used a single variable
that advanced through the chain:
while (g) {
g->topo_levels = &topo_levels;
g = g->base_graph;
}
The refactored code introduced a separate iteration variable but did not
update the loop body to match:
for (struct commit_graph *chain = g; chain; chain = chain->base_graph)
g->topo_levels = &topo_levels;
This always assigns to the topmost layer instead of the current one. Commits
from lower layers appear to have no generation numbers, so the DFS re-walks
the entire ancestry.
On a repo with a multi-layer split commit-graph, an incremental commit-graph
write triggered by git fetch drops from ~3.5 seconds to ~0.2 seconds after
the fix.
[1]
https://lore.kernel.org/git/aMNTELw0Wk8jWoPc@nand.local/T/#mb55b5f0e1ccf82d969ac1d8144c56ecf87b833e8
Changes since v1:
* Fixed wrong commit title and date in the reference (Junio, Taylor).
* use test_expect_failure with the correct assertion instead of a # BUG
comment (Taylor).
* Simplified commit messages.
Kristofer Karlsson (2):
commit-graph: add trace2 instrumentation for generation DFS
commit-graph: propagate topo_levels slab to all chain layers
commit-graph.c | 7 ++++++-
t/t5324-split-commit-graph.sh | 24 ++++++++++++++++++++++++
2 files changed, 30 insertions(+), 1 deletion(-)
base-commit: f85a7e662054a7b0d9070e432508831afa214b47
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2170%2Fspkrka%2Fkrka%2Ffix-topo-levels-slab-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2170/spkrka/krka/fix-topo-levels-slab-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/2170
Range-diff vs v1:
1: b865c2bcff ! 1: 100efa22a9 commit-graph: add trace2 instrumentation for generation DFS
@@ Metadata
## Commit message ##
commit-graph: add trace2 instrumentation for generation DFS
- Add a step counter and trace2_data_intmax call to
- compute_reachable_generation_numbers() to make the cost of
- the generation number DFS observable. This exposes a
- regression introduced in 199d452758 (commit-graph: fix
- "filling in" topological levels, 2025-04-07) where
- incremental commit-graph writes re-walk the entire commit
- ancestry instead of reading topo levels from lower graph
- layers.
+ Count the number of steps taken in
+ compute_reachable_generation_numbers() and expose it via
+ trace2 to make it easier to detect performance regressions.
- Add a test that demonstrates the problem: with a two-layer
- split commit-graph, writing a new incremental layer for a
- commit whose parent is in the base layer walks all the way
- down to the root (7 steps for 5 base commits) instead of
- reading the existing topo level and stopping immediately
- (1 step).
+ Add a failing test for such a regression, introduced in
+ 199d452758 (commit-graph: return the prepared commit graph
+ from `prepare_commit_graph()`, 2025-09-04), where incremental
+ commit-graph writes do not see existing generation numbers
+ from lower graph layers and fall back to walking the full
+ ancestry.
Signed-off-by: Kristofer Karlsson <krka@spotify.com>
@@ t/t5324-split-commit-graph.sh: test_expect_success 'write generation data chunk
)
'
-+test_expect_success 'incremental write reads topo levels from all layers' '
++test_expect_failure 'incremental write reads topo levels from all layers' '
+ git init topo-from-lower &&
+ (
+ cd topo-from-lower &&
@@ t/t5324-split-commit-graph.sh: test_expect_success 'write generation data chunk
+ GIT_TRACE2_EVENT="$(pwd)/trace.txt" \
+ git commit-graph write --reachable --split=no-merge &&
+
-+ # BUG: topo levels from lower graph layers are not
-+ # propagated, so the DFS re-walks from base-3 down to
-+ # the root (7 steps) instead of reading topo levels
-+ # from the existing graph (1 step).
-+ test_trace2_data commit-graph generation-dfs-steps 7 <trace.txt
++ test_trace2_data commit-graph generation-dfs-steps 1 <trace.txt
+ )
+'
+
2: f9c1482a76 ! 2: 679dd2e392 commit-graph: propagate topo_levels slab to all chain layers
@@ Metadata
## Commit message ##
commit-graph: propagate topo_levels slab to all chain layers
- Fix a regression introduced in 199d452758 (commit-graph: fix
- "filling in" topological levels, 2025-04-07) where the loop
- propagating the topo_levels slab to each layer of the
- commit-graph chain always assigned to `g->topo_levels`
- (the topmost layer) instead of `chain->topo_levels` (the
- current iteration variable).
+ The topo_levels slab is only propagated to the topmost graph
+ layer instead of all layers in the chain. Commits from lower
+ layers appear to have no generation numbers, so the DFS
+ re-walks the entire ancestry.
- This meant only the topmost layer had its topo_levels pointer
- set. When compute_reachable_generation_numbers() ran for an
- incremental write, commits parsed from lower layers had their
- topo levels left at zero in the slab, since
- fill_commit_graph_info() could not store them without the
- pointer. The DFS then re-walked the entire commit ancestry
- instead of stopping at commits with known levels.
-
- On a repository with 2.78M commits and a multi-layer split
- commit-graph, this caused a single incremental commit-graph
- write to spend ~3.7 seconds in the generation DFS instead of
- microseconds.
+ Fix by making topo_levels visible to all layers, not just
+ the first one.
Signed-off-by: Kristofer Karlsson <krka@spotify.com>
@@ commit-graph.c: int write_commit_graph(struct odb_source *source,
ctx.changed_paths = 1;
## t/t5324-split-commit-graph.sh ##
-@@ t/t5324-split-commit-graph.sh: test_expect_success 'incremental write reads topo levels from all layers' '
- GIT_TRACE2_EVENT="$(pwd)/trace.txt" \
- git commit-graph write --reachable --split=no-merge &&
-
-- # BUG: topo levels from lower graph layers are not
-- # propagated, so the DFS re-walks from base-3 down to
-- # the root (7 steps) instead of reading topo levels
-- # from the existing graph (1 step).
-- test_trace2_data commit-graph generation-dfs-steps 7 <trace.txt
-+ test_trace2_data commit-graph generation-dfs-steps 1 <trace.txt
+@@ t/t5324-split-commit-graph.sh: test_expect_success 'write generation data chunk when commit-graph chain is repl
)
'
+-test_expect_failure 'incremental write reads topo levels from all layers' '
++test_expect_success 'incremental write reads topo levels from all layers' '
+ git init topo-from-lower &&
+ (
+ cd topo-from-lower &&
--
gitgitgadget
next prev parent reply other threads:[~2026-07-09 15:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 9:59 [PATCH 0/2] commit-graph: fix topo_levels slab propagation regression Kristofer Karlsson via GitGitGadget
2026-07-07 9:59 ` [PATCH 1/2] commit-graph: add trace2 instrumentation for generation DFS Kristofer Karlsson via GitGitGadget
2026-07-07 13:46 ` Taylor Blau
2026-07-07 14:08 ` Kristofer Karlsson
2026-07-10 22:09 ` Taylor Blau
2026-07-10 22:28 ` Junio C Hamano
2026-07-10 22:56 ` Taylor Blau
2026-07-11 21:18 ` Junio C Hamano
2026-07-13 19:55 ` Kristofer Karlsson
2026-07-13 20:42 ` Junio C Hamano
2026-07-13 22:17 ` Kristofer Karlsson
2026-07-07 16:55 ` Junio C Hamano
2026-07-07 17:39 ` Kristofer Karlsson
2026-07-07 9:59 ` [PATCH 2/2] commit-graph: propagate topo_levels slab to all chain layers Kristofer Karlsson via GitGitGadget
2026-07-07 13:49 ` Taylor Blau
2026-07-07 14:02 ` Kristofer Karlsson
2026-07-07 14:57 ` Kristofer Karlsson
2026-07-10 22:14 ` Taylor Blau
2026-07-13 6:16 ` Patrick Steinhardt
2026-07-14 3:31 ` Taylor Blau
2026-07-07 17:00 ` Junio C Hamano
2026-07-07 17:42 ` Kristofer Karlsson
2026-07-07 20:13 ` Junio C Hamano
2026-07-09 13:43 ` Patrick Steinhardt
2026-07-09 15:02 ` Kristofer Karlsson via GitGitGadget [this message]
2026-07-09 15:03 ` [PATCH v2 1/2] commit-graph: add trace2 instrumentation for generation DFS Kristofer Karlsson via GitGitGadget
2026-07-09 15:03 ` [PATCH v2 2/2] commit-graph: propagate topo_levels slab to all chain layers Kristofer Karlsson via GitGitGadget
2026-07-10 22:15 ` [PATCH v2 0/2] commit-graph: fix topo_levels slab propagation regression Taylor Blau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pull.2170.v2.git.1783609382.gitgitgadget@gmail.com \
--to=gitgitgadget@gmail.com \
--cc=git@vger.kernel.org \
--cc=krka@spotify.com \
--cc=me@ttaylorr.com \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox