| Message ID | 9fc71f4511b163bec53616d82e8fe5214facf060.1640927044.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | RFC: Server side merges (no ref updating, no commit creating, no touching worktree or index) | expand |
On Fri, Dec 31, 2021 at 05:04:00AM +0000, Elijah Newren via GitGitGadget wrote: > From: Elijah Newren <newren@gmail.com> > > This adds the ability to perform real merges rather than just trivial > merges (meaning handling three way content merges, recursive ancestor > consolidation, renames, proper directory/file conflict handling, and so > forth). However, unlike `git merge`, the working tree and index are > left alone and no branch is updated. > > The only output is: > - the toplevel resulting tree printed on stdout > - exit status of 0 (clean) or 1 (conflicts present) > > This output is mean to be used by some higher level script, perhaps in a > sequence of steps like this: > > NEWTREE=$(git merge-tree --real $BRANCH1 $BRANCH2) > test $? -eq 0 || die "There were conflicts..." > NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 $BRANCH2) > git update-ref $BRANCH1 $NEWCOMMIT > > Note that higher level scripts may also want to access the > conflict/warning messages normally output during a merge, or have quick > access to a list of files with conflicts. That is not available in this > preliminary implementation, but subsequent commits will add that > ability. > > Signed-off-by: Elijah Newren <newren@gmail.com> > --- > Documentation/git-merge-tree.txt | 28 +++++++---- > builtin/merge-tree.c | 55 +++++++++++++++++++++- > t/t4301-merge-tree-real.sh | 81 ++++++++++++++++++++++++++++++++ > 3 files changed, 153 insertions(+), 11 deletions(-) > create mode 100755 t/t4301-merge-tree-real.sh > > diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt > index 58731c19422..5823938937f 100644 > --- a/Documentation/git-merge-tree.txt > +++ b/Documentation/git-merge-tree.txt > @@ -3,26 +3,34 @@ git-merge-tree(1) > > NAME > ---- > -git-merge-tree - Show three-way merge without touching index > +git-merge-tree - Perform merge without touching index or working tree > > > SYNOPSIS > -------- > [verse] > +'git merge-tree' --real <branch1> <branch2> > 'git merge-tree' <base-tree> <branch1> <branch2> This is really exciting. It could replace the merge-machinery of git-revise (which is a "fast rebase" tool). I think for cherry-pick/rebase we need to specify a custom merge base, would that suit the new form?
On Sat, Jan 1, 2022 at 12:08 PM Johannes Altmanninger <aclopte@gmail.com> wrote: > > On Fri, Dec 31, 2021 at 05:04:00AM +0000, Elijah Newren via GitGitGadget wrote: > > From: Elijah Newren <newren@gmail.com> > > > > This adds the ability to perform real merges rather than just trivial > > merges (meaning handling three way content merges, recursive ancestor > > consolidation, renames, proper directory/file conflict handling, and so > > forth). However, unlike `git merge`, the working tree and index are > > left alone and no branch is updated. > > > > The only output is: > > - the toplevel resulting tree printed on stdout > > - exit status of 0 (clean) or 1 (conflicts present) > > > > This output is mean to be used by some higher level script, perhaps in a > > sequence of steps like this: > > > > NEWTREE=$(git merge-tree --real $BRANCH1 $BRANCH2) > > test $? -eq 0 || die "There were conflicts..." > > NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 $BRANCH2) > > git update-ref $BRANCH1 $NEWCOMMIT > > > > Note that higher level scripts may also want to access the > > conflict/warning messages normally output during a merge, or have quick > > access to a list of files with conflicts. That is not available in this > > preliminary implementation, but subsequent commits will add that > > ability. > > > > Signed-off-by: Elijah Newren <newren@gmail.com> > > --- > > Documentation/git-merge-tree.txt | 28 +++++++---- > > builtin/merge-tree.c | 55 +++++++++++++++++++++- > > t/t4301-merge-tree-real.sh | 81 ++++++++++++++++++++++++++++++++ > > 3 files changed, 153 insertions(+), 11 deletions(-) > > create mode 100755 t/t4301-merge-tree-real.sh > > > > diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt > > index 58731c19422..5823938937f 100644 > > --- a/Documentation/git-merge-tree.txt > > +++ b/Documentation/git-merge-tree.txt > > @@ -3,26 +3,34 @@ git-merge-tree(1) > > > > NAME > > ---- > > -git-merge-tree - Show three-way merge without touching index > > +git-merge-tree - Perform merge without touching index or working tree > > > > > > SYNOPSIS > > -------- > > [verse] > > +'git merge-tree' --real <branch1> <branch2> > > 'git merge-tree' <base-tree> <branch1> <branch2> > > This is really exciting. It could replace the merge-machinery of git-revise > (which is a "fast rebase" tool). > I think for cherry-pick/rebase we need to specify a custom merge base, > would that suit the new form? I'm glad you're excited about it. :-) I think having a server side tool for replaying commits (which can double as a fast rebase/cherry-pick tool on the client side) is also important, but I think it should be part of a proper builtin, not some script that calls out to `merge-tree --real`. `merge-tree --real` is simpler, though, so I implemented and submitted it first.
On 31.12.2021 05:04, Elijah Newren via GitGitGadget wrote: >From: Elijah Newren <newren@gmail.com> > >This adds the ability to perform real merges rather than just trivial >merges (meaning handling three way content merges, recursive ancestor >consolidation, renames, proper directory/file conflict handling, and so >forth). However, unlike `git merge`, the working tree and index are >left alone and no branch is updated. > >The only output is: > - the toplevel resulting tree printed on stdout > - exit status of 0 (clean) or 1 (conflicts present) > >This output is mean to be used by some higher level script, perhaps in a >sequence of steps like this: > > NEWTREE=$(git merge-tree --real $BRANCH1 $BRANCH2) > test $? -eq 0 || die "There were conflicts..." > NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 $BRANCH2) > git update-ref $BRANCH1 $NEWCOMMIT > >Note that higher level scripts may also want to access the >conflict/warning messages normally output during a merge, or have quick >access to a list of files with conflicts. That is not available in this >preliminary implementation, but subsequent commits will add that >ability. > >Signed-off-by: Elijah Newren <newren@gmail.com> >--- > Documentation/git-merge-tree.txt | 28 +++++++---- > builtin/merge-tree.c | 55 +++++++++++++++++++++- > t/t4301-merge-tree-real.sh | 81 ++++++++++++++++++++++++++++++++ > 3 files changed, 153 insertions(+), 11 deletions(-) > create mode 100755 t/t4301-merge-tree-real.sh > >diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt >index 58731c19422..5823938937f 100644 >--- a/Documentation/git-merge-tree.txt >+++ b/Documentation/git-merge-tree.txt >@@ -3,26 +3,34 @@ git-merge-tree(1) > > NAME > ---- >-git-merge-tree - Show three-way merge without touching index >+git-merge-tree - Perform merge without touching index or working tree > > > SYNOPSIS > -------- > [verse] >+'git merge-tree' --real <branch1> <branch2> > 'git merge-tree' <base-tree> <branch1> <branch2> > > DESCRIPTION > ----------- >-Reads three tree-ish, and output trivial merge results and >-conflicting stages to the standard output. This is similar to >-what three-way 'git read-tree -m' does, but instead of storing the >-results in the index, the command outputs the entries to the >-standard output. >+Performs a merge, but does not make any new commits and does not read >+from or write to either the working tree or index. > >-This is meant to be used by higher level scripts to compute >-merge results outside of the index, and stuff the results back into the >-index. For this reason, the output from the command omits >-entries that match the <branch1> tree. >+The first form will merge the two branches, doing a full recursive >+merge with rename detection. If the merge is clean, the exit status >+will be `0`, and if the merge has conflicts, the exit status will be >+`1`. The output will consist solely of the resulting toplevel tree >+(which may have files including conflict markers). >+ >+The second form is meant for backward compatibility and will only do a >+trival merge. It reads three tree-ish, and outputs trivial merge >+results and conflicting stages to the standard output in a semi-diff >+format. Since this was designed for higher level scripts to consume >+and merge the results back into the index, it omits entries that match >+<branch1>. The result of this second form is is similar to what >+three-way 'git read-tree -m' does, but instead of storing the results >+in the index, the command outputs the entries to the standard output. > > GIT > --- >diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c >index f04b1eaad0a..c5757bed5bb 100644 >--- a/builtin/merge-tree.c >+++ b/builtin/merge-tree.c >@@ -2,6 +2,9 @@ > #include "builtin.h" > #include "tree-walk.h" > #include "xdiff-interface.h" >+#include "help.h" >+#include "commit-reach.h" >+#include "merge-ort.h" > #include "object-store.h" > #include "parse-options.h" > #include "repository.h" >@@ -391,7 +394,57 @@ struct merge_tree_options { > static int real_merge(struct merge_tree_options *o, > const char *branch1, const char *branch2) > { >- die(_("real merges are not yet implemented")); >+ struct commit *parent1, *parent2; >+ struct commit_list *common; >+ struct commit_list *merge_bases = NULL; >+ struct commit_list *j; >+ struct merge_options opt; >+ struct merge_result result = { 0 }; >+ >+ parent1 = get_merge_parent(branch1); >+ if (!parent1) >+ help_unknown_ref(branch1, "merge", >+ _("not something we can merge")); >+ >+ parent2 = get_merge_parent(branch2); >+ if (!parent2) >+ help_unknown_ref(branch2, "merge", >+ _("not something we can merge")); >+ >+ init_merge_options(&opt, the_repository); >+ /* >+ * TODO: Support subtree and other -X options? >+ if (use_strategies_nr == 1 && >+ !strcmp(use_strategies[0]->name, "subtree")) >+ opt.subtree_shift = ""; >+ for (x = 0; x < xopts_nr; x++) >+ if (parse_merge_opt(&opt, xopts[x])) >+ die(_("Unknown strategy option: -X%s"), xopts[x]); >+ */ >+ >+ opt.show_rename_progress = 0; >+ >+ opt.branch1 = merge_remote_util(parent1)->name; /* or just branch1? */ >+ opt.branch2 = merge_remote_util(parent2)->name; /* or just branch2? */ >+ >+ /* >+ * Get the merge bases, in reverse order; see comment above >+ * merge_incore_recursive in merge-ort.h >+ */ >+ common = get_merge_bases(parent1, parent2); >+ for (j = common; j; j = j->next) >+ commit_list_insert(j->item, &merge_bases); >+ >+ /* >+ * TODO: notify if merging unrelated histories? >+ if (!common) >+ fprintf(stderr, _("merging unrelated histories")); >+ */ >+ >+ merge_incore_recursive(&opt, merge_bases, parent1, parent2, &result); >+ printf("%s\n", oid_to_hex(&result.tree->object.oid)); >+ merge_switch_to_result(&opt, NULL, &result, 0, 0); >+ return result.clean ? 0 : 1; > } > > int cmd_merge_tree(int argc, const char **argv, const char *prefix) >diff --git a/t/t4301-merge-tree-real.sh b/t/t4301-merge-tree-real.sh >new file mode 100755 >index 00000000000..9fb617ccc7f >--- /dev/null >+++ b/t/t4301-merge-tree-real.sh >@@ -0,0 +1,81 @@ >+#!/bin/sh >+ >+test_description='git merge-tree --real' >+ >+. ./test-lib.sh >+ >+# This test is ort-specific >+GIT_TEST_MERGE_ALGORITHM=ort >+export GIT_TEST_MERGE_ALGORITHM >+ >+test_expect_success setup ' >+ test_write_lines 1 2 3 4 5 >numbers && >+ echo hello >greeting && >+ echo foo >whatever && >+ git add numbers greeting whatever && >+ git commit -m initial && >+ >+ git branch side1 && >+ git branch side2 && >+ >+ git checkout side1 && >+ test_write_lines 1 2 3 4 5 6 >numbers && >+ echo hi >greeting && >+ echo bar >whatever && >+ git add numbers greeting whatever && >+ git commit -m rename-and-modify && The commit implies a rename as well which I think is missing. >+ >+ git checkout side2 && >+ test_write_lines 0 1 2 3 4 5 >numbers && >+ echo yo >greeting && >+ git rm whatever && >+ mkdir whatever && >+ >whatever/empty && >+ git add numbers greeting whatever/empty && >+ git commit -m remove-and-rename And this looks more like a remove-and-modify. Is it still a rename when we empty the files content? >+' >+ >+test_expect_success 'Content merge and a few conflicts' ' >+ git checkout side1^0 && >+ test_must_fail git merge side2 && >+ cp .git/AUTO_MERGE EXPECT && >+ E_TREE=$(cat EXPECT) && >+ >+ git reset --hard && >+ test_must_fail git merge-tree --real side1 side2 >RESULT && >+ R_TREE=$(cat RESULT) && >+ >+ # Due to differences of e.g. "HEAD" vs "side1", the results will not >+ # exactly match. Dig into individual files. >+ >+ # Numbers should have three-way merged cleanly >+ test_write_lines 0 1 2 3 4 5 6 >expect && >+ git show ${R_TREE}:numbers >actual && >+ test_cmp expect actual && >+ >+ # whatever and whatever~<branch> should have same HASHES >+ git rev-parse ${E_TREE}:whatever ${E_TREE}:whatever~HEAD >expect && >+ git rev-parse ${R_TREE}:whatever ${R_TREE}:whatever~side1 >actual && >+ test_cmp expect actual && >+ >+ # greeting should have a merge conflict >+ git show ${E_TREE}:greeting >tmp && >+ cat tmp | sed -e s/HEAD/side1/ >expect && >+ git show ${R_TREE}:greeting >actual && >+ test_cmp expect actual >+' >+ >+test_expect_success 'Barf on misspelled option' ' >+ # Mis-spell with single "s" instead of double "s" >+ test_expect_code 129 git merge-tree --real --mesages FOOBAR side1 side2 2>expect && >+ >+ grep "error: unknown option.*mesages" expect >+' >+ >+test_expect_success 'Barf on too many arguments' ' >+ test_expect_code 129 git merge-tree --real side1 side2 side3 2>expect && >+ >+ grep "^usage: git merge-tree" expect >+' >+ >+test_done >-- >gitgitgadget >
On Mon, Jan 3, 2022 at 4:23 AM Fabian Stelzer <fs@gigacodes.de> wrote: > > On 31.12.2021 05:04, Elijah Newren via GitGitGadget wrote: > >From: Elijah Newren <newren@gmail.com> > > > >This adds the ability to perform real merges rather than just trivial > >merges (meaning handling three way content merges, recursive ancestor > >consolidation, renames, proper directory/file conflict handling, and so > >forth). However, unlike `git merge`, the working tree and index are > >left alone and no branch is updated. > > ... > >+test_expect_success setup ' > >+ test_write_lines 1 2 3 4 5 >numbers && > >+ echo hello >greeting && > >+ echo foo >whatever && > >+ git add numbers greeting whatever && > >+ git commit -m initial && > >+ > >+ git branch side1 && > >+ git branch side2 && > >+ > >+ git checkout side1 && > >+ test_write_lines 1 2 3 4 5 6 >numbers && > >+ echo hi >greeting && > >+ echo bar >whatever && > >+ git add numbers greeting whatever && > >+ git commit -m rename-and-modify && > > The commit implies a rename as well which I think is missing. Sorry, I revised the testcase (multiple times) and forgot to update this commit message string. > >+ > >+ git checkout side2 && > >+ test_write_lines 0 1 2 3 4 5 >numbers && > >+ echo yo >greeting && > >+ git rm whatever && > >+ mkdir whatever && > >+ >whatever/empty && > >+ git add numbers greeting whatever/empty && > >+ git commit -m remove-and-rename > > And this looks more like a remove-and-modify. Likewise. I'll fix these up; thanks for pointing them out.
diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt index 58731c19422..5823938937f 100644 --- a/Documentation/git-merge-tree.txt +++ b/Documentation/git-merge-tree.txt @@ -3,26 +3,34 @@ git-merge-tree(1) NAME ---- -git-merge-tree - Show three-way merge without touching index +git-merge-tree - Perform merge without touching index or working tree SYNOPSIS -------- [verse] +'git merge-tree' --real <branch1> <branch2> 'git merge-tree' <base-tree> <branch1> <branch2> DESCRIPTION ----------- -Reads three tree-ish, and output trivial merge results and -conflicting stages to the standard output. This is similar to -what three-way 'git read-tree -m' does, but instead of storing the -results in the index, the command outputs the entries to the -standard output. +Performs a merge, but does not make any new commits and does not read +from or write to either the working tree or index. -This is meant to be used by higher level scripts to compute -merge results outside of the index, and stuff the results back into the -index. For this reason, the output from the command omits -entries that match the <branch1> tree. +The first form will merge the two branches, doing a full recursive +merge with rename detection. If the merge is clean, the exit status +will be `0`, and if the merge has conflicts, the exit status will be +`1`. The output will consist solely of the resulting toplevel tree +(which may have files including conflict markers). + +The second form is meant for backward compatibility and will only do a +trival merge. It reads three tree-ish, and outputs trivial merge +results and conflicting stages to the standard output in a semi-diff +format. Since this was designed for higher level scripts to consume +and merge the results back into the index, it omits entries that match +<branch1>. The result of this second form is is similar to what +three-way 'git read-tree -m' does, but instead of storing the results +in the index, the command outputs the entries to the standard output. GIT --- diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c index f04b1eaad0a..c5757bed5bb 100644 --- a/builtin/merge-tree.c +++ b/builtin/merge-tree.c @@ -2,6 +2,9 @@ #include "builtin.h" #include "tree-walk.h" #include "xdiff-interface.h" +#include "help.h" +#include "commit-reach.h" +#include "merge-ort.h" #include "object-store.h" #include "parse-options.h" #include "repository.h" @@ -391,7 +394,57 @@ struct merge_tree_options { static int real_merge(struct merge_tree_options *o, const char *branch1, const char *branch2) { - die(_("real merges are not yet implemented")); + struct commit *parent1, *parent2; + struct commit_list *common; + struct commit_list *merge_bases = NULL; + struct commit_list *j; + struct merge_options opt; + struct merge_result result = { 0 }; + + parent1 = get_merge_parent(branch1); + if (!parent1) + help_unknown_ref(branch1, "merge", + _("not something we can merge")); + + parent2 = get_merge_parent(branch2); + if (!parent2) + help_unknown_ref(branch2, "merge", + _("not something we can merge")); + + init_merge_options(&opt, the_repository); + /* + * TODO: Support subtree and other -X options? + if (use_strategies_nr == 1 && + !strcmp(use_strategies[0]->name, "subtree")) + opt.subtree_shift = ""; + for (x = 0; x < xopts_nr; x++) + if (parse_merge_opt(&opt, xopts[x])) + die(_("Unknown strategy option: -X%s"), xopts[x]); + */ + + opt.show_rename_progress = 0; + + opt.branch1 = merge_remote_util(parent1)->name; /* or just branch1? */ + opt.branch2 = merge_remote_util(parent2)->name; /* or just branch2? */ + + /* + * Get the merge bases, in reverse order; see comment above + * merge_incore_recursive in merge-ort.h + */ + common = get_merge_bases(parent1, parent2); + for (j = common; j; j = j->next) + commit_list_insert(j->item, &merge_bases); + + /* + * TODO: notify if merging unrelated histories? + if (!common) + fprintf(stderr, _("merging unrelated histories")); + */ + + merge_incore_recursive(&opt, merge_bases, parent1, parent2, &result); + printf("%s\n", oid_to_hex(&result.tree->object.oid)); + merge_switch_to_result(&opt, NULL, &result, 0, 0); + return result.clean ? 0 : 1; } int cmd_merge_tree(int argc, const char **argv, const char *prefix) diff --git a/t/t4301-merge-tree-real.sh b/t/t4301-merge-tree-real.sh new file mode 100755 index 00000000000..9fb617ccc7f --- /dev/null +++ b/t/t4301-merge-tree-real.sh @@ -0,0 +1,81 @@ +#!/bin/sh + +test_description='git merge-tree --real' + +. ./test-lib.sh + +# This test is ort-specific +GIT_TEST_MERGE_ALGORITHM=ort +export GIT_TEST_MERGE_ALGORITHM + +test_expect_success setup ' + test_write_lines 1 2 3 4 5 >numbers && + echo hello >greeting && + echo foo >whatever && + git add numbers greeting whatever && + git commit -m initial && + + git branch side1 && + git branch side2 && + + git checkout side1 && + test_write_lines 1 2 3 4 5 6 >numbers && + echo hi >greeting && + echo bar >whatever && + git add numbers greeting whatever && + git commit -m rename-and-modify && + + git checkout side2 && + test_write_lines 0 1 2 3 4 5 >numbers && + echo yo >greeting && + git rm whatever && + mkdir whatever && + >whatever/empty && + git add numbers greeting whatever/empty && + git commit -m remove-and-rename +' + +test_expect_success 'Content merge and a few conflicts' ' + git checkout side1^0 && + test_must_fail git merge side2 && + cp .git/AUTO_MERGE EXPECT && + E_TREE=$(cat EXPECT) && + + git reset --hard && + test_must_fail git merge-tree --real side1 side2 >RESULT && + R_TREE=$(cat RESULT) && + + # Due to differences of e.g. "HEAD" vs "side1", the results will not + # exactly match. Dig into individual files. + + # Numbers should have three-way merged cleanly + test_write_lines 0 1 2 3 4 5 6 >expect && + git show ${R_TREE}:numbers >actual && + test_cmp expect actual && + + # whatever and whatever~<branch> should have same HASHES + git rev-parse ${E_TREE}:whatever ${E_TREE}:whatever~HEAD >expect && + git rev-parse ${R_TREE}:whatever ${R_TREE}:whatever~side1 >actual && + test_cmp expect actual && + + # greeting should have a merge conflict + git show ${E_TREE}:greeting >tmp && + cat tmp | sed -e s/HEAD/side1/ >expect && + git show ${R_TREE}:greeting >actual && + test_cmp expect actual +' + +test_expect_success 'Barf on misspelled option' ' + # Mis-spell with single "s" instead of double "s" + test_expect_code 129 git merge-tree --real --mesages FOOBAR side1 side2 2>expect && + + grep "error: unknown option.*mesages" expect +' + +test_expect_success 'Barf on too many arguments' ' + test_expect_code 129 git merge-tree --real side1 side2 side3 2>expect && + + grep "^usage: git merge-tree" expect +' + +test_done