One of the big unstated aspects is the distinction between --automatic and --interactive expectations. The main Git project has the assumption of --automatic merges without any need for user intervention. That's on the assumption of a 'clean' workflow with proper separation of concerns, small changes, short lived branches and all that good stuff. There is also the expectation that the code change and commits will be readable and understandable in hindsight / maintenance. This all drives the 'No conflicts' rule.
But as we all know the more general reality is the "Big Ball of Mud" development process (or at least that's where our problems are ;-). In these cases it will be an --interactive muddy merge, usually with multiple participants. Either because they each contributed a branch to your octopus, or they each had an area and files of interest when the mega-feature (single branch) is being merged, and no single person can resolve the combined conflict (there have been discussions on that). I suspect that what is needed is a half way house that acknowledges both positions and offers a Partial Merge (or muddy merge (tm)). This needs a method of capturing the 'per person / branch' staged changes, and the final 'global' octopus, so that the simplified history is one of the single mega merge, all done in one magic step, but beneath that is the details of the partial merges. On Monday, May 16, 2022 at 5:45:20 AM UTC+1 johannes.lipp...@gmail.com wrote: > Very interesting, thank you. Especially that this discussion has been so > recent indeed. > > So after reading through that thread I had a look at git-merge-octopus.sh > <https://git.kernel.org/pub/scm/git/git.git/tree/git-merge-octopus.sh?h=main> > itself. > I understand that it is a design decision to not to make octopus merges > with manual conflict resolution easy. > I still think that that is a petty and that it would be useful. > On the other hand, implementing it would mean reimplementing > git-merge-octopus almost completely. > > So I guess I will just hack together a custom solution for me. > If I should stumble about a solution that can be generalized somewhat > easily then I will report back. > > Thanks a lot, > Johannes > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/d0afebca-8078-4df4-b4eb-59aa66ad65aan%40googlegroups.com.
