Skip to content

Accelerate "git merge-base --is-ancestor"

Derrick Stolee via GitGitGadget git 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest2 patches 5 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/2commit-reach: create repo_is_descendant_of()commit-reach.c+9 -22 replies
2/2commit-reach: use fast logic in repo_in_merge_basecommit-reach.c+10 -20 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/2] Accelerate "git merge-base --is-ancestor"

It was recently [1] reported (and not-so-recently [2] reported) that "git merge-base --is-ancestor" can be pretty slow. In fact, it is regularly slower than "git branch --contains" or "git tag --contains", which are answering a "harder" query.

[1] https://lore.kernel.org/git/[email protected]/

[2] https://lore.kernel.org/git/[email protected]/

The root cause is that the in_merge_base() implementation is skipping the fast can_all_from_reach() implementation and using paint_down_to_common() instead. Note that these are equivalent: a commit A is in the set of merge-bases between A and B if and only if B can reach A.

This fixes the issue, and makes the performance degradation reported by Szeder a non-issue.

Thanks, -Stolee

Derrick Stolee (2):
commit-reach: create repo_is_descendant_of()
commit-reach: use fast logic in repo_in_merge_base

 commit-reach.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

base-commit: b3d7a52fac39193503a0b6728771d1bf6a161464
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-664%2Fderrickstolee%2Fmerge-base-is-ancestor-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-664/derrickstolee/merge-base-is-ancestor-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/664

Signature · 1 line
gitgitgadget