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". 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.) 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).
