Just to get some of my ideas 'down on paper', here are some notes I made of
the concept.
The Partial, or Muddy Merge (tm)
This presumes we have a conflicted merge so this is interactive merge
strategy.
We initialise the muddy-merge by creating a multi parent merge commit MM-0.
This comprises:-
1st parent: Current HEAD (this is/will be the progressive tip of the merge
2nd parent: Current HEAD (this is the mergebase tip)
3rd parent: first branch to be merged (possibly the single mudball branch
4+th parent: second & subsequent octopus branches to be merged.
tree: Current HEAD's tree.
The duplicate entry for P1 & P2 is the indicator for the start of the muddy
merge (also that there's a P3, etc).
The deadhead of this initial muddy merge commit's tree being identical to
that of the first parent could also be a useful indicator - see the GfW
release merges)
The next partial/muddy merge commit (MM-1) has the same format but the 1st
parent commit is that of the muddy merge initialiser, and the tree has
progressed with the partial/muddy merge, and the merge commit explains that
step.
After a sequence of these muddy merges we have the P1 and tree values
progressing, while P2-n are the unchanged reference points of the whole
muddy merge.
These could be simple file merges by subject matter experts (SMEs) or
composite branch merges to resolve multiple conflicts within this window.
I.e. Usual ball of mud progression.
Eventually we have a completed merge commit (MM-N) that contains the final
tree, but we haven't tided up loose ends to present a single-step clean
merge, along with a side stream of how it happened. This muddy merge MM-N
still has the P1,P2-n parent arrangement.
The desired result is that the first parent history shows / implies a
single clean merge. It also requires (user dependant) a supplementary
commit that has a "spare" second parent pointing to the muddy merge
sequence (but unchanged tree) (technique borrowed from GfW).
Case A: Finalise with side notes
The finalised merge commit (MM-final) uses the P2-n commit list of
contributors (the P2 being the original MM-0 HEAD, i.e. one less parents),
with the final tree.
The supplemental commit (MM-side) then has P1=finalised commit,
P2=completed side merge commit, same tree; commit message that its the side
merge.
Case B: Finalise without side notes (aka squashed notes.) as per finalised
as above, but the auto-merge message includes oid to the squashed notes
commit). Reflog, possible tag, extra ref, or temp branch.
Case C: as Case B but no mention of the side note oid hash in the merge
message. reflog.
Note the suplemental commit can be 'simplified' with a '--deadhead' option
(if implementated)
--> implied time
```
main: A - B - MMfinal - MMside - ->
\ // /
mudball: XYz - . - . /
\\ \ /
muddymerge MM0 - MM1,MM2 - MM-N
```
Was ASCII art..
commit parentage & tree
XYz: one or more branch tips. Alludes to XY-problem & more, doing the wrong
thing righter; theory is nice, but reality bite.
MM0: B,B,XYz;treeB (all MMx commits are octopus)
MM1: MM0,B,XYz;treeMM1
MMN: MM(N-1),B,XYz;treeMMN
MMfinal: B,XYz:treeMMN
MMside: B,MMN;treeMMN (2-parent merge)
Philip
On Monday, May 16, 2022 at 1:20:36 PM UTC+1 Philip Oakley wrote:
> 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 [email protected]
> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/9ab86ec2-1ca2-49b6-97ed-4c45cf93501dn%40googlegroups.com.
