[hsenag]

It's based on "patches" (which was what the original comment was referring to).

A Darcs patch is somewhat like a diff, in that most patches will describe a sequence of text to be removed and added from specific points in each file.

But: Darcs patches add:

- The ability to work out precisely how to apply the same patch in a different context in a reproducible way (or to refuse to do so if it can't do it safely) - More "semantic" kinds of change such as replacing all occurrences of a token in a file, or renaming a file. In both cases this will merge cleanly and reproducibly with other changes to the same file.

[bernds74]

To me this has always sounded like the kind of error-prone excessive cleverness that I wouldn't want anywhere near my version control system.

[hsenag]

You could always go back to emailing around file changes :-)

Most VCSes including git have some level of complicated algorithms behind them. Darcs does have significant weaknesses when it comes to handling conflicts but the core logic of figuring out how to apply changes to files has been pretty solid for its entire existence.

[adastra22]

It’s the same thing that happens every time you rebase or cherry pick commits in git.

[Nullabillity]

A version control system always needs to consider both, to some extent.

The difference is in which is the primary source of truth, and which is calculated when required (and then thrown away).

[adastra22]

There are more concerns than that. In got “A -> B -> C” generates one hash, while “A -> C -> B” is a different hash. In Pijul they are the same.

This may seem trivial, but the darcs/pijul approach permits an entirely different, more distributed/decentralized development model.

Ironically a model better suited to kernel development.

[ltbarcly3]

It's a thing that nobody is smart enough to use and didn't actually work, but hey at least Darcs is also 1000x slower than git and will lose data!