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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/20200607195347.GA8232@xxxxxxxxxx/

[2] https://lore.kernel.org/git/87608bawoa.fsf@xxxxxxxxxxxxxxxxxxx/

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
-- 
gitgitgadget



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux