From: ZheNing Hu <firstname.lastname@example.org>
To: Elijah Newren <email@example.com>
Cc: Christian Couder <firstname.lastname@example.org>,
Git List <email@example.com>,
Junio C Hamano <firstname.lastname@example.org>,
Subject: Re: Question about pre-merge and git merge octopus strategy
Date: Sun, 8 May 2022 22:44:43 +0800 [thread overview]
Message-ID: <CAOLTT8STRfqq4bfobCK8Q5uvtXzgNYY0x0wNh4HNyAhv0Mc07A@mail.gmail.com> (raw)
Elijah Newren <email@example.com> 于2022年5月7日周六 12:09写道：
> On Fri, May 6, 2022 at 10:24 AM Christian Couder
> <firstname.lastname@example.org> wrote:
> > Hi,
> > On Fri, May 6, 2022 at 10:15 AM ZheNing Hu <email@example.com> 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".
I have see the code of git-merge-octopus.sh, it run merge-base,
read-tree, write-tree every loop.
Now I get you about it's hard to do multiple tree merge because it's hard to
express in index.
> 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
I'll be looking forward to this feature!
> 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).
Thanks for clarifying. As I reply to Christian, when I just use "git
merge A B C" happily,
and there is a conflict, so I try "git merge --abort" as usual, but it
can not work... git tell me:
fatal: There is no merge to abort (MERGE_HEAD missing).
> > 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).
I think this AUTO_MERGE maybe a good thing for checking merge conflicts,
maybe it will help git merge-octopus.
next prev parent reply other threads:[~2022-05-08 14:44 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
2022-05-07 18:37 ` Junio C Hamano
2022-05-08 14:44 ` ZheNing Hu [this message]
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
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: http://vger.kernel.org/majordomo-info.html
* 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).