git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 0/7] Rejecting useless merge bases

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 19, 2016, 04:23 UTC
Message-ID
<20161019042345.29766-1-gitster@pobox.com>
In-Reply-To
<xmqqmvi2sj8f.fsf@gitster.mtv.corp.google.com>
This is a continuation of
    http://public-inbox.org/git/xmqqmvi2sj8f.fsf@gitster.mtv.corp.google.com

In a workflow where topic branches are first merged to the 'next' integration branch to be tested before getting merged down to the 'master' integration branch to be consumed by the end users, merging the 'master' branch back to the 'next' happens after topics graduate to 'master' and release notes entries are written for them.

Git finds many merge bases between 'master' and 'next' while creating this merge. In addition to the tip of 'master' back when we made such a merge back from 'master' to 'next' was made the last time, which is the most reasonable merge base to explain the histories of both branches, all the tips of topic branches that graduated recently are merge bases. Because these tips of topic branches were already in 'next', the tip of 'next' reaches them, and because they just graduated to 'master', the tip of 'master' reaches them, too. And these topics are independent most of the time (that is the point of employing the topic-branch workflow), so they cannot be reduced.

The merge-recursive machinery is very inefficient to compute this merge, because it needs to create pointless virtual merge-base commits across these many merge bases. Conceptually, the point where the histories of 'master' and 'next' diverged was the tip of 'master' back when we created such a merge back from 'master' to 'next' the last time, and in practice that is the only merge base that matters.

The series allows us to ignore these tips of topics, which are uninteresting merge bases, when running "git merge". The example merge with 12 merge bases:

    git checkout 4868def05e && git merge 659889482a

in our history takes about 1.22-1.33 seconds without the series, while running the latter "git merge" with the "--fp-base-only" option takes about 0.54-0.59 seconds.

Junio C Hamano (7):
  commit: simplify fastpath of merge-base
  sha1_name: remove ONELINE_SEEN bit
  merge-base: stop moving commits around in remove_redundant()
  merge-base: expose get_merge_bases_many_0() a bit more
  merge-base: mark bases that are on first-parent chain
  merge-base: limit the output to bases that are on first-parent chain
  merge: allow to use only the fp-only merge bases
 Documentation/git-merge-base.txt |  8 +++-
 Documentation/merge-options.txt  |  9 +++++
 builtin/merge-base.c             | 10 +++--
 builtin/merge.c                  | 15 ++++++--
 commit.c                         | 81 ++++++++++++++++++++++++----------------
 commit.h                         |  7 +++-
 object.h                         |  3 +-
 sha1_name.c                      | 10 ++---
 8 files changed, 94 insertions(+), 49 deletions(-)
-- 
2.10.1-631-gb2c64dcf30
Previous: Junio C HamanoNext: Junio C Hamano
Message 2 of 13 in “[RFD] should all merge bases be equal?”
  1. Junio C HamanoOct 17, 2016
  2. 0/7 Rejecting useless merge basesJunio C Hamano, Oct 19, 2016
  3. 1/7 commit: simplify fastpath of merge-base computationJunio C Hamano, Oct 19, 2016
  4. 3/7 merge-base: stop moving commits around in remove_redundant()Junio C Hamano, Oct 19, 2016
  5. 2/7 sha1_name: remove ONELINE_SEEN bitJunio C Hamano, Oct 19, 2016
  6. 4/7 merge-base: expose get_merge_bases_many_0() a bit moreJunio C Hamano, Oct 19, 2016
  7. 5/7 merge-base: mark bases that are on first-parent chainJunio C Hamano, Oct 19, 2016
  8. Junio C HamanoOct 19, 2016
  9. 6/7 merge-base: limit the output to bases that are on first-parent chainJunio C Hamano, Oct 19, 2016
  10. 7/7 merge: allow to use only the fp-only merge basesJunio C Hamano, Oct 19, 2016
  11. Junio C HamanoOct 19, 2016
  12. Michael HaggertyFeb 9, 2017
  13. Junio C HamanoFeb 9, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.