Fix commit-graph v1 regression in v2.55.0#954
Draft
dscho wants to merge 2 commits into
Draft
Conversation
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>
paint_down_to_common() regression in v2.55.0
Member
Author
derrickstolee
approved these changes
Jul 9, 2026
44992e5 to
ae68032
Compare
Member
Author
|
Oops. By resolving the merge conflicts via 44992e5, I accidentally updated the branch in |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Junio has marked Kristofer's
paint_down_to_common()fix fornext(lore), but the topic has not yet graduated tomaster. This PR is a backport ontovfs-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 inpaint_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, andgit merge-base(without--all) can silently return a non-best answer. The tip commit git/git@ae68032a8d0 threads agen_orderedflag 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()pinscommitGraph.generationVersion=1(scalar.c:191), and that pin is applied on everyscalar clone,scalar register, andscalar reconfigure. Stolee introduced it in 18580f020d1 as a deliberate but temporary compatibility measure for existing enlistments with v1 graphs on disk, with the accompanyingDocumentation/scalar.adocnote 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.