list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <>
To: Christian Couder <>
Cc: ZheNing Hu <>,
	Git List <>,
	Junio C Hamano <>,
Subject: Re: Question about pre-merge and git merge octopus strategy
Date: Fri, 6 May 2022 21:09:45 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, May 6, 2022 at 10:24 AM Christian Couder
<> wrote:
> Hi,
> On Fri, May 6, 2022 at 10:15 AM ZheNing Hu <> wrote:
> > I am thinking about if git can "pre-merge" multiple branches, which
> > can check if merge
> > will have conflict, but not to merge them actually, like a option `--intend`.
> >
> > I find "git merge-tree" can output merge result in stdout, which meets
> > my needs, but it can only
> > support two branches' merge.
> Elijah (added in Cc) has been working on "git merge-tree" improvements
> based on the new "ort" merge he developed. It supports merging 2
> branches, but maybe there are ways to make it support more than 2.

The primary issue with in-core octopus merges is that there are lots
of questions about how to handle conflicts; possibly even more so than
git merge-tree --write-tree brings up, and that took us months of
discussion.  In particular, with octopii, do iterate merging one
branch in at a time and stop with any conflicts (thus potentially
stopping N-1 times when merging N branches), do you attempt to just
run all N-1 merges and have conflicts that can't readily be expressed
in the index (especially for non-textual multi-way conflicts, but even
nested conflict markers for text files could be painful), do you
attempt to handle the multi-way textual conflicts a new way with code
replacing xdiff/ in order to avoid nested conflicts?  I wasn't sure
what to do, so never implemented that in "ort".

Of course, people could roll their own by just serially merging pairs
of commits, and then rewriting the history to replace the string of
merges with an octopus.  Or perhaps just use "git merge --no-commit"
serially, though that only works if the branches touch disjoint files
(otherwise one of the merges will complain you have changes that could
be overwritten by the next merge).  And yes, if you don't want to mess
with the working tree/index, you could serially use the "git
merge-tree --write-tree" once I finish it, but it's not ready yet.
(Sorry about that; I've got a bunch of nearly complete changes from a
while ago but just didn't have much Git time.  I'll try to get to it

However, I think Junio said that octopus merge only handles trivial
cases anyway, in which case an iterated "git merge --write-tree" would
actually be a sufficient solution here and we could sidestep the more
convoluted cases.  But, sadly for ZheNing, that option doesn't exist
yet -- It's still under development.

> > So I find git merge with more than two branches can use octopus strategy.
> > What about git merge --no-commit? Which will not commit automatically,
> > so we can check if they have
> > confilct, and abort merge.
> Yeah, I think that's what you want.
> > I think it's not useful for git merge-octopus, because if we meet a
> > merge conflict, we can't find
> > MERGE_HEAD at all! How can we abort this conflict merge?

MERGE_HEAD doesn't have anything to do with aborting the conflict
resolution step.  When you need to abort, the thing you want to go
back to is HEAD (which represents the commit you had checked out and
were merging the other stuff into), not MERGE_HEAD (which represents
the branch or branches you were merging into HEAD).

> I don't know octopus merges much, but I think you should be able to
> abort using "git reset" (maybe with "--hard").  If the merge was
> performed using --no-commit or if there was a conflict, then I think
> it should be expected that there is no MERGE_HEAD as no commit would
> be created so MERGE_HEAD would have nothing to point to.

MERGE_HEAD isn't something created during a merge, it's something that
existed before it -- namely, the tip of the other branch we are
merging.  For an octopus merge, you'd thus expect it to have N commits
rather than just 1.

AUTO_MERGE, new to ort, is something that is created during a merge
and when the merge interrupts due to conflicts to ask the user to
resolve the conflicts, AUTO_MERGE represents the tree checked out in
the working copy (thus it is a tree that likely has files with
conflict markers in them).

  reply	other threads:[~2022-05-07  4:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06  8:14 ZheNing Hu
2022-05-06 17:23 ` Christian Couder
2022-05-07  4:09   ` Elijah Newren [this message]
2022-05-07 18:37     ` Junio C Hamano
2022-05-08 14:44     ` ZheNing Hu
2022-05-10  7:07       ` Elijah Newren
2022-05-11 11:21         ` ZheNing Hu
2022-05-12 15:04           ` Elijah Newren
2022-05-12 15:39             ` Junio C Hamano
2022-05-13  5:15               ` Elijah Newren
2022-05-13 12:56                 ` Junio C Hamano
2022-05-19 13:15                 ` ZheNing Hu
2022-05-19 14:46                   ` Elijah Newren
2022-05-08 14:13   ` ZheNing Hu
2022-05-08 15:01 ` Carlo Marcelo Arenas Belón

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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \

* 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.
Code repositories for project(s) associated with this inbox:

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 read-only IMAP folder(s) and NNTP newsgroup(s).