Elijah Newren <newren@xxxxxxxxx> 于2022年5月7日周六 12:09写道： > > On Fri, May 6, 2022 at 10:24 AM Christian Couder > <christian.couder@xxxxxxxxx> wrote: > > > > Hi, > > > > On Fri, May 6, 2022 at 10:15 AM ZheNing Hu <adlternative@xxxxxxxxx> 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 > soon.) > 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. Thanks.
