Much like everyone else who wants to engage as little as possible with "here are some effective threats to make the computer do what you want" while still learning about exciting new computer things, I have been learning how to use Jujutsu. I recently had my epiphany insight where it all clicked and I understood the mental model (which I will not share, because of theory).

Something this has me reflecting on is how "reconcile these two divergent histories" is a surprisingly common operation in computers, given how weird it is. I've written before about how version control and database consistency are very closely related, and this is of course a reflection of an underlying fact that they are both instances of reconciling concurrent access to a shared data structure.

It's sort of interesting to contrast how these two different approaches handle resolving conflicts. In version control, users are required to resolve conflicts by hand. In database-land, conflicts mean one user has to start completely over. These two things are...sort of the same in some sense, if you view "resolving conflicts" as "starting from scratch with the knowledge of what both commits were attempting to accomplish."

But what I think is sort of interesting about this operation is that it's pretty nonlocal: you cannot just look at the state of the repo at the two tips you're trying to merge and figure out the result, you need to know their common ancestor to know which version actually has a change and which left things unchanged. So it's actually fairly nuanced, this tool that every programmer must use to do their work. You absolutely must understand the diverging histories nature for merges to make, really, any sense at all.

Now, big merges in Git can be a bit tedious and manual, because Git refuses to proceed with a merge if there are conflicts, and asks you to manually resolve them. Jujutsu says "we can just leave the conflict markers in the code" and continues. In this way, they sort of just say "nothing ever really conflicts, because we can come up with a result that is the merge of two changes no matter what."

Timely dataflow takes this a step further and defines the way that changes are resolved as always needing to be conflict-free. Everything is a map of keys to semigroups. This sounds like it would be very restrictive, and it is, but the power of the computations that can be expressed here more than make up for it. The ability to do iteration means you can compute many complex things in this model, as long as they're graph traversal.

This has interesting consequences: because you are always guaranteed to be able to reconcile any histories, you can run hypotheticals about what happens when you join them together at various different possible merge points.

This is not to mention the various notions of time and history that come up in the study of distributed systems. In that world, generally people say conflicts should just be avoided, either by using some kind of conflict-free data model, or by not acting on any object you don't have unilateral control over.

What I'm getting at is that this notion of "strategies for resolving divergent histories" is actually extremely common and it seems to me we don't have universal language for it that encapsulates all these different use cases. What seems universal to me is the presence of partial orders as language for thinking about these things, but in my experience programmers don't have all that good intuition around what partial orders even are, or how they behave. It doesn't help that the Rust standard library lies about what a partial order is.

I think any kind of universal theory of history reconciliation would need to encompass all of the above situations:

• Version control, with an explicit DAG of changes,
• transaction processing,
• abstract, partial notions of time as in Timely Dataflow, and
• distributed systems notions of time as seen in things like Lamport clocks.

I think one could certainly construct a theory that taxonomizes all these situations and conflict-resolution strategies. Perhaps someone has! If that's you please let me know!