pr-1587/BobaFetters/zf/multi-subtree-processing-v4
tagged this
26 Oct 19:17
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. Added a test to validate that the proposed fix solves the issue. The test accomplishes this by checking the output of the split command to ensure the output from the progress of 'process_split_commit' function that represents the 'extracount' of commits processed does not increment. This was tested against the original functionality to show the test failed, and then with this fix to show the test passes. This illustrated that when using multiple subtrees, A and B, when doing a split on subtree B, the processing does not traverse the entire history of subtree A which is unnecessary and would cause the 'extracount' of processed commits to climb based on the number of commits in the history of subtree A. Signed-off-by: Zach FettersMoore <zach.fetters@apollographql.com> Submitted-As: https://lore.kernel.org/git/pull.1587.v4.git.1698347871200.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.1587.git.1695067516192.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.1587.v2.git.1695399920.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.1587.v3.git.1696019580.gitgitgadget@gmail.com
Assets 2
-
2023-10-26T19:17:51Z -
2023-10-26T19:17:51Z -