The state of merging technology

The piece of BitKeeper I wish people would steal is the smerge gca conflict format. See <a href="https:&#x2F;&#x2F;www.bitkeeper.org&#x2F;man&#x2F;smerge.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.bitkeeper.org&#x2F;man&#x2F;smerge.html</a> Example:<p><pre><code> &lt;&lt;&lt;&lt;&lt;&lt;&lt; local slib.c 1.642.1.6 vs 1.645 sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s-&gt;proj); - assert(sc-&gt;tree); - sccs_sdelta(sc, sc-&gt;tree, file); + assert(HASGRAPH(sc)); + sccs_sdelta(sc, sccs_ino(sc), file); &lt;&lt;&lt;&lt;&lt;&lt;&lt; remote slib.c 1.642.1.6 vs 1.642.2.1 - sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s-&gt;proj); + sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p); assert(sc-&gt;tree); sccs_sdelta(sc, sc-&gt;tree, file); &gt;&gt;&gt;&gt;&gt;&gt;&gt; </code></pre> Here we have a code conflict and rather than showing you what the file looks like on the two sides it shows you what was changed on both sides relative to the GCA. So we get two unified diffs. The local side made this edit, while on the remote side we had that edit. Then it is obvious how to resolve the conflict without losing a change.<p>This works for the cris-cross case because that GCA is really a set of common revisions merged together.

some relevant context is that bram and his brother ross developed an early decentralized version control system named &#x27;codeville&#x27;, more or less contemporary with git and mercurial; they put a lot of work into figuring out how merging should handle different hairy scenarios<p>bram was deeply disappointed that the systems that got widely adopted, like git, did a terrible job with these hairy scenarios, since he knew that it was possible to do much better

Didn&#x27;t Git have a new default merge strategy, `ort` <a href="https:&#x2F;&#x2F;github.com&#x2F;git&#x2F;git&#x2F;blob&#x2F;master&#x2F;Documentation&#x2F;RelNotes&#x2F;2.34.0.txt">https:&#x2F;&#x2F;github.com&#x2F;git&#x2F;git&#x2F;blob&#x2F;master&#x2F;Documentation&#x2F;RelNote...</a> ?

The biggest day-to-day merge conflict annoyance I have is situations like this. As far as I know, there’s no solution:<p><pre><code> commit aaaaaaaa diff --git a&#x2F;README.md b&#x2F;README.md --- a&#x2F;README.md +++ b&#x2F;README.md @@ -1,4 +1,4 @@ -&lt;p align=&quot;center&quot;&gt; +&lt;p align=&quot;left&quot;&gt; &lt;img width=&quot;200&quot; src=&quot;logo.svg&quot;&gt; &lt;&#x2F;p&gt; commit bbbbbbbb diff --git a&#x2F;README.md b&#x2F;README.md --- a&#x2F;README.md +++ b&#x2F;README.md @@ -1,5 +1,5 @@ &lt;p align=&quot;center&quot;&gt; - &lt;img width=&quot;200&quot; src=&quot;logo.svg&quot;&gt; + &lt;img width=&quot;345&quot; src=&quot;logo.svg&quot;&gt; &lt;&#x2F;p&gt; # Project </code></pre> Commit aaaaaaaa changes some text on line 1.<p>Commit bbbbbbbb changes some unrelated text on line 2.<p>I don’t want to have to manually resolve this—just merge the lines. If there’s a semantic conflict I’ll let the tests sort it out. When I’ve looked in the past there wasn’t a merge strategy that fixes this.

&gt; The next easiest win would be to use the weave algorithm for non-rebase merges.<p>The weave is essentially a CRDT, but invented in 1977 by SCCS. Anyone interested in weaves should consider modern CRDT tech. I&#x27;ve been keeping some notes on the correspondence within the Braid.org group (e.g. <a href="https:&#x2F;&#x2F;braid.org&#x2F;meeting-60&#x2F;sccs-is-a-time-collapse" rel="nofollow noreferrer">https:&#x2F;&#x2F;braid.org&#x2F;meeting-60&#x2F;sccs-is-a-time-collapse</a>) and encourage anyone interested to reach out!