You left out the thing that was awesome about darcs, that pijul could do too: real cherry pick,where picking a change also tracked down the other patches needed for that, you could literally pull whole features from one tree to another, not just a commit.

It was marvelous with darcs.

Isn't that describing `git merge <commit>`? (The whole point of cherry-pick being that you specifically DON'T want anything but the one commit)

Edit: Never mind, I see that darcs patches are not equivalent to git commits (and maybe not to anything in git).

> On the other hand, if I'm being honest, all of my really hairy merge conflicts are not things that I think could be resolved by this---not without changing the way we think about code from being about text to being about ASTs.

With the trend towards automatic code formatting, I don’t think that would be difficult to do.

I think this is where things could go—VCS aware of semantics—which could happen if syntax==semantics.

> The other part is the theory of patches. Darcs took the lead here too, but the algorithms and implementation left something to be desired.

For what it's worth, there's a Darcs 3 in development, with a new patch format/theory, thanks to the two keeping it alive. Find darcs 2 generally pleasant enough with a fairly large code base. I didn't understand the reason for not keeping the darcs interface with new guts for pjiul.

Yep. I’ve used darcs for at least a decade. The mental model is just so straightforward, I simply never wrestling with it. It does exactly what I want with very little thought. I’ve transitioned to git this last year and my head hurts constantly.

Things that used to be trivial are now unsolvable (by me at least).

The darcs ui was a complete joy. Interactive but super fast. Incredibly easy for new uses to learn.

Conflicts can't be avoided (certainly not by tree-diffing), and aren't an error state ("conflict" is a bad name because it sounds like it is). The useful innovation of pijul is that conflicted states are not an exceptional state - you can continue to apply patches.

I understand that conflicts are inevitable, but wouldn't tree-diffing at least be an improvement over line-diffing? I recall that Pijul's theory of generalized files (arbitrary digraphs of lines IIRC) is already fairly complicated though.

It wouldn't really make much of a difference, if any. For source files, anyway - more complicated diffing helps for files we consider just "binary" now but that are actually structured.

Pijul's pushouts are unrelated - that just allows a line in a file to be ambiguous, rather than definitely being one line.

You say Pijul's pushouts are unrelated, but their construction depends on a very line-centric definition of patches. Wouldn't it need to be made more complex to accomodate tree patches?

No? The concept is that a unit of diffing (a line, or a tree node in your hypothetical tree-diffing approach) can be ambiguous until another patch resolves the ambiguity.

In the vaguest sense, sure. But if a file is a list of lines, this "ambiguous file" is a digraph of lines. If a file is instead a tree of strings, what does an "ambiguous file" look like? See this paper which was the source of some of the main ideas of Pijul, and in particular, note that its extension to structured data is listed as "future work", which means it probably hasn't been done yet.

https://arxiv.org/pdf/1311.3903.pdf

I don't think you have understood the pushouts paper. Look at figure 4 again.

Which one's figure 4? They're not numbered.

Also, can you point out what my misunderstanding is? That'd help a lot.

A tool that handles a frequent but not particularly challenging problem is still a net win. Humans make errors. The more times I have to do something manually, the higher the likelihood I have screwed one of them up. I don't expect to get better at doing a task the 101st time. But I do expect the odds that one of them gets cocked up to climb ever so slightly. Better if the machine can just do it.

If the majority of the code is written by middle-of-the-road team members, then most of the merges will be done by those same people. Something that never helps me with my changes still helps me, due to my shared responsibility for the project. This is an often overlooked aspect of the tool selection process.