New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
merge-ort: implement recursive merges #814
Conversation
/submit |
Submitted as pull.814.git.1608054807.gitgitgadget@gmail.com To fetch this version into
To fetch this version to local tag
|
This branch is now known as |
This patch series was integrated into seen via git@33fcba7. |
User |
82a773d
to
d8f7945
Compare
/submit |
Submitted as pull.814.v2.git.1608097965.gitgitgadget@gmail.com To fetch this version into
To fetch this version to local tag
|
User |
d8f7945
to
e50e77e
Compare
User |
e50e77e
to
59216a1
Compare
/submit |
Submitted as pull.814.v3.git.1608139034.gitgitgadget@gmail.com To fetch this version into
To fetch this version to local tag
|
59216a1
to
f622d69
Compare
User |
/submit |
Submitted as pull.814.v4.git.1608150919.gitgitgadget@gmail.com To fetch this version into
To fetch this version to local tag
|
Signed-off-by: Elijah Newren <newren@gmail.com>
In a subsequent commit, we will implement the traditional recursiveness that gave merge-recursive its name, namely merging non-unique merge-bases to come up with a single virtual merge base. Copy a few helper functions from merge-recursive.c that we will use in the implementation. Signed-off-by: Elijah Newren <newren@gmail.com>
In order to handle recursive merges, after merging merge-bases we need to clear away most of the data we had built up but some of it needs to be kept -- in particular the "output" field. Rename the function to reflect its future change in use. Further, since "reinitialize" means we'll be reusing the fields immediately, take advantage of this to only partially clear maps, leaving the hashtable allocated and pre-sized. (This may be slightly out-of-order since the speedups aren't realized until there are far more strmaps in use, but the patch submission process already went out of order because of various questions and requests for strmap. Anyway, see commit 6ccdfc2 ("strmap: enable faster clearing and reusing of strmaps", 2020-11-05), for performance details about the use of strmap_partial_clear().) Signed-off-by: Elijah Newren <newren@gmail.com>
Implement merge_incore_recursive(), mostly through the use of a new helper function, merge_ort_internal(), which itself is based off merge_recursive_internal() from merge-recursive.c. This drops the number of failures in the testsuite when run under GIT_TEST_MERGE_ALGORITHM=ort from around 1500 to 647. Signed-off-by: Elijah Newren <newren@gmail.com>
f622d69
to
63e3049
Compare
/submit |
Submitted as pull.814.v5.git.1608157682.gitgitgadget@gmail.com To fetch this version into
To fetch this version to local tag
|
This patch series was integrated into seen via git@99a2fe7. |
This patch series was integrated into seen via git@7068b2c. |
@@ -563,6 +563,17 @@ struct commit_list *copy_commit_list(struct commit_list *list) | |||
return head; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the Git mailing list, Derrick Stolee wrote (reply to this):
On 12/16/2020 5:27 PM, Elijah Newren via GitGitGadget wrote:
> +struct commit_list *reverse_commit_list(struct commit_list *list)
> +{
> + struct commit_list *next = NULL, *current, *backup;
> + for (current = list; current; current = backup) {
> + backup = current->next;
> + current->next = next;
> + next = current;
> + }
> + return next;
> +}
> +
I followed the discussion about the variable names in
the earlier thread, and I certainly did not meant to
stir a controversy. I think this approach of deduplicating
but keeping an exact copy is the best solution.
Thanks,
-Stolee
This patch series was integrated into seen via git@c6d5321. |
This patch series was integrated into seen via git@e89950b. |
This patch series was integrated into seen via git@e90bb62. |
This patch series was integrated into seen via git@396a7bb. |
This patch series was integrated into seen via git@874da60. |
This patch series was integrated into seen via git@8694dec. |
This patch series was integrated into next via git@0dbf600. |
This patch series was integrated into seen via git@2e2eb01. |
This patch series was integrated into seen via git@88ece5f. |
This patch series was integrated into seen via git@e3f0861. |
This patch series was integrated into seen via git@45a1770. |
This patch series was integrated into next via git@45a1770. |
This patch series was integrated into master via git@45a1770. |
Closed via 45a1770. |
This series depends on en/merge-ort-2 (it does NOT depend on en/merge-ort-3 and can thus be reviewed/merged independently of it).
This short series adds handling of recursive merges (merging of multiple merge-bases to create a virtual merge base) to merge-ort. With this short series the number of test failures under GIT_TEST_MERGE_ALGORITHM=ort drops by 801 (from 1448 to 647).
Changes since v4:
cc: Elijah Newren newren@gmail.com
cc: Derrick Stolee stolee@gmail.com
cc: Johannes Schindelin Johannes.Schindelin@gmx.de
cc: Felipe Contreras felipe.contreras@gmail.com