On Fri, Dec 31, 2021 at 05:04:00AM +0000, Elijah Newren via GitGitGadget wrote: > From: Elijah Newren <newren@xxxxxxxxx> > > 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@xxxxxxxxx> > --- > 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?
