Skip to content

Fix commit-graph v1 regression in v2.55.0#954

Draft
dscho wants to merge 2 commits into
microsoft:vfs-2.55.0from
gitgitgadget:kk/commit-reach-find-all-fix
Draft

Fix commit-graph v1 regression in v2.55.0#954
dscho wants to merge 2 commits into
microsoft:vfs-2.55.0from
gitgitgadget:kk/commit-reach-find-all-fix

Conversation

@dscho

@dscho dscho commented Jul 9, 2026

Copy link
Copy Markdown
Member

Junio has marked Kristofer's paint_down_to_common() fix for next (lore), but the topic has not yet graduated to master. This PR is a backport onto vfs-2.55.0, queued while upstream finishes cooking.

The regression was introduced by git/git@93e5b1680e (merged as git/git@6390da42c7) and first shipped in v2.55.0, which is why the base here is vfs-2.55.0. That commit added a fast-path early exit in paint_down_to_common() predicated on the priority queue being generation-ordered. The predicate holds under the generation-then-date ordering, but the same function falls back to plain commit-date ordering when !min_generation && !corrected_commit_dates_enabled(r), which is true whenever the loaded commit-graph lacks a GDAT chunk (i.e. a v1 graph). Under that fallback the early exit is unsound: with clock skew, a closer merge base can sit behind deeper commits in the queue, and git merge-base (without --all) can silently return a non-best answer. The tip commit git/git@ae68032a8d0 threads a gen_ordered flag through and gates the early exit on it.

The reason microsoft/git in particular needs to carry this promptly, rather than wait the usual weeks for upstream graduation, is Scalar. set_recommended_config() pins commitGraph.generationVersion=1 (scalar.c:191), and that pin is applied on every scalar clone, scalar register, and scalar reconfigure. Stolee introduced it in 18580f020d1 as a deliberate but temporary compatibility measure for existing enlistments with v1 graphs on disk, with the accompanying Documentation/scalar.adoc note calling out that v2 is preferred and the pin is expected to change once the upgrade story solidifies. Every Scalar-managed enlistment on microsoft/git 2.55.x therefore lands on exactly the broken code path, and Scalar's target audience (Office monorepos and external adopters) is precisely the large-monorepo, many-active-branches cohort Kristofer's original optimization was aimed at in the first place.

spkrka added 2 commits June 29, 2026 10:40
Add a topology where the correct merge base (M2) has a lower
committer date than its ancestor (M1) due to clock skew.  With a
v1 commit graph (topological levels only, no corrected commit
dates), paint_down_to_common() falls back to commit-date ordering.
In that mode, M1 pops before M2, acquires both paint sides, and
the !FIND_ALL early exit fires -- returning the wrong merge base.

Mark the test as test_expect_failure to document the bug; the next
commit will fix it.

Signed-off-by: Kristofer Karlsson <krka@spotify.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When paint_down_to_common() falls back to commit-date ordering (for
v1 commit graphs without corrected commit dates), the !FIND_ALL early
exit incorrectly fires.  The exit assumes the queue is generation-
ordered, so the first RESULT commit found must be the shallowest.
With date ordering this is not guaranteed: a closer merge base with
a lower committer date (clock skew) may still be in the queue behind
deeper commits.

Add a gen_ordered flag that is cleared when the date fallback fires,
and require it for the early exit.

Update the test from the previous commit to test_expect_success.

Signed-off-by: Kristofer Karlsson <krka@spotify.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
@dscho dscho changed the title commit-reach: backport upstream fix for paint_down_to_common() regression in v2.55.0 Fix commit-graph v1 regression in v2.55.0 Jul 9, 2026
@dscho dscho self-assigned this Jul 9, 2026
@dscho

dscho commented Jul 9, 2026

Copy link
Copy Markdown
Member Author
image

Oh joy:

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/resolute-updates/main/binary-amd64/Packages.gz  File has unexpected size (389887 != 390231). Mirror sync in progress? [IP: 91.189.91.83 80]
   Hashes of expected file:
    - Filesize:390231 [weak]
    - SHA256:0217165e131bb2fb1c06af993d9079bc48b6c14bbed6bdc694388c0c52796e47
    - SHA1:cc8376847d0c2f0dc74d0a889529d697efd22329 [weak]
    - MD5Sum:a6e6770bc58978c6dd8b048fd6024e15 [weak]
   Release file created at: Thu, 09 Jul 2026 08:20:08 +0000
E: Some index files failed to download. They have been ignored, or old ones used instead.

I love it when my PR Checks fail for reasons that are totally outside my control...</s>

@gitgitgadget gitgitgadget Bot force-pushed the kk/commit-reach-find-all-fix branch from 44992e5 to ae68032 Compare July 9, 2026 23:48
@dscho

dscho commented Jul 10, 2026

Copy link
Copy Markdown
Member Author

Oops. By resolving the merge conflicts via 44992e5, I accidentally updated the branch in gitgitgadget/git, which the GitGitGadget automation rectified by undoing my merge. I'll have to push that merge conflict to vfs-2.55.0 (once the kk/commit-reach-find-all-fix topic graduates to next, which should be soon).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants