git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Zach FettersMoore via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: Zach FettersMoore <zach.fetters@apollographql.com>,
	Zach FettersMoore <zach.fetters@apollographql.com>
Subject: [PATCH] subtree: fix split processing with multiple subtrees present
Date: Mon, 18 Sep 2023 20:05:16 +0000	[thread overview]
Message-ID: <pull.1587.git.1695067516192.gitgitgadget@gmail.com> (raw)

From: Zach FettersMoore <zach.fetters@apollographql.com>

When there are multiple subtrees present in a repository and they are
all using 'git subtree split', the 'split' command can take a
significant (and constantly growing) amount of time to run even when
using the '--rejoin' flag. This is due to the fact that when processing
commits to determine the last known split to start from when looking
for changes, if there has been a split/merge done from another subtree
there will be 2 split commits, one mainline and one subtree, for the
second subtree that are part of the processing. The non-mainline
subtree split commit will cause the processing to always need to search
the entire history of the given subtree as part of its processing even
though those commits are totally irrelevant to the current subtree
split being run.

In the diagram below, 'M' represents the mainline repo branch, 'A'
represents one subtree, and 'B' represents another. M3 and B1 represent
a split commit for subtree B that was created from commit M4. M2 and A1
represent a split commit made from subtree A that was also created
based on changes back to and including M4. M1 represents new changes to
the repo, in this scenario if you try to run a 'git subtree split
--rejoin' for subtree B, commits M1, M2, and A1, will be included in
the processing of changes for the new split commit since the last
split/rejoin for subtree B was at M3. The issue is that by having A1
included in this processing the command ends up needing to processing
every commit down tree A even though none of that is needed or relevant
to the current command and result.

M1
 |	  \	  \
M2	   |	   |
 |     	  A1	   |
M3	   |	   |
 |	   |	  B1
M4	   |	   |

So this commit makes a change to the processing of commits for the split
command in order to ignore non-mainline commits from other subtrees such
as A1 in the diagram by adding a new function
'should_ignore_subtree_commit' which is called during
'process_split_commit'. This allows the split/rejoin processing to still
function as expected but removes all of the unnecessary processing that
takes place currently which greatly inflates the processing time.

Signed-off-by: Zach FettersMoore <zach.fetters@apollographql.com>
---
    subtree: fix split processing with multiple subtrees present
    
    When there are multiple subtrees in a repo and git subtree split
    --rejoin is being used for the subtrees, the processing of commits for a
    new split can take a significant (and constantly growing) amount of time
    because the split commits from other subtrees cause the processing to
    have to scan the entire history of the other subtree(s). This patch
    filters out the other subtree split commits that are unnecessary for the
    split commit processing.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1587%2FBobaFetters%2Fzf%2Fmulti-subtree-processing-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1587/BobaFetters/zf/multi-subtree-processing-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1587

 contrib/subtree/git-subtree.sh | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index e0c5d3b0de6..e9250dfb019 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -778,12 +778,29 @@ ensure_valid_ref_format () {
 		die "fatal: '$1' does not look like a ref"
 }
 
+# Usage: check if a commit from another subtree should be ignored from processing for splits
+should_ignore_subtree_commit () {
+  if [ "$(git log -1 --grep="git-subtree-dir:" $1)" ]
+  then
+    if [[ -z "$(git log -1 --grep="git-subtree-mainline:" $1)" && -z "$(git log -1 --grep="git-subtree-dir: $dir$" $1)" ]]
+    then
+      return 0
+    fi
+  fi
+  return 1
+}
+
 # Usage: process_split_commit REV PARENTS
 process_split_commit () {
 	assert test $# = 2
 	local rev="$1"
 	local parents="$2"
 
+    if should_ignore_subtree_commit $rev
+    then
+	    return
+    fi
+
 	if test $indent -eq 0
 	then
 		revcount=$(($revcount + 1))

base-commit: bda494f4043963b9ec9a1ecd4b19b7d1cd9a0518
-- 
gitgitgadget

             reply	other threads:[~2023-09-18 20:05 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-18 20:05 Zach FettersMoore via GitGitGadget [this message]
2023-09-18 23:31 ` [PATCH] subtree: fix split processing with multiple subtrees present Junio C Hamano
2023-09-19  1:04 ` Junio C Hamano
2023-10-26 19:59   ` Zach FettersMoore
2023-09-22 16:25 ` [PATCH v2 0/2] " Zach FettersMoore via GitGitGadget
2023-09-22 16:25   ` [PATCH v2 1/2] " Zach FettersMoore via GitGitGadget
2023-09-22 16:25   ` [PATCH v2 2/2] subtree: changing location of commit ignore processing Zach FettersMoore via GitGitGadget
2023-09-29 20:32   ` [PATCH v3 0/3] subtree: fix split processing with multiple subtrees present Zach FettersMoore via GitGitGadget
2023-09-29 20:32     ` [PATCH v3 1/3] " Zach FettersMoore via GitGitGadget
2023-09-29 20:32     ` [PATCH v3 2/3] subtree: changing location of commit ignore processing Zach FettersMoore via GitGitGadget
2023-09-29 20:33     ` [PATCH v3 3/3] subtree: adding test to validate fix Zach FettersMoore via GitGitGadget
2023-10-17 20:02       ` Zach FettersMoore
2023-10-26 19:17     ` [PATCH v4] subtree: fix split processing with multiple subtrees present Zach FettersMoore via GitGitGadget
2023-11-18 11:28       ` Christian Couder
2023-11-28 21:04         ` Zach FettersMoore
2023-11-28 21:17       ` [PATCH v5] " Zach FettersMoore via GitGitGadget
2023-11-30 20:33         ` Christian Couder
2023-11-30 21:01           ` Zach FettersMoore
2023-12-01 14:54         ` [PATCH v6] " Zach FettersMoore via GitGitGadget
2023-12-04 11:08           ` Christian Couder
2023-12-11 15:39             ` Zach FettersMoore
2023-12-12 16:06               ` Christian Couder
2023-12-12 22:28                 ` Junio C Hamano
2023-12-13 15:20                   ` Zach FettersMoore
2024-01-03 16:33                     ` Christian Couder
2023-12-20 15:25                 ` Christian Couder
2024-01-25 10:09                   ` Christian Couder
2024-01-25 16:38                     ` Junio C Hamano
2024-01-25 18:52                       ` Christian Couder
2024-01-25 18:56                         ` Junio C Hamano
2025-08-21  3:13           ` subtree: [v2.44 regression] split may produce different history Colin Stagner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pull.1587.git.1695067516192.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=zach.fetters@apollographql.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).