Git (and nearly every other version control system) the state of the repository is an ordered list of changes. This is massively oversimplified of course, as in git it is a tree rather than a list as in CVS/SVN, and git is actually storing snapshots rather than diffs, but whatever. That doesn't matter here. Traditional version control is an ordered list of changes, and that ordering is what matters here.
In darcs/pijul, the state of the repository is a *set* of order-independent changes/patches. I don't know about darcs, but pijul even uses clever homographic hashing so that the commit hash after applying patches A, B, and C (in that order) is the same as if you did C -> A -> B, or any other permutation.
In Linux kernel dev, for example, developers think of a particular build as "upstream 6.13.2 with zfs and realtime patchsets applied" but in reality in any given instance it is actually "6.13.2 -> zfs -> realtime" or "6.13.2 -> realtime -> zfs" depending on which order you cherry-pick/rebase the patches. Both have different git hashes and are properly speaking different things. In pijul it would be "6.13.2 + zfs + realtime" and the order doesn't matter.
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.
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.
In darcs/pijul, the state of the repository is a *set* of order-independent changes/patches. I don't know about darcs, but pijul even uses clever homographic hashing so that the commit hash after applying patches A, B, and C (in that order) is the same as if you did C -> A -> B, or any other permutation.
In Linux kernel dev, for example, developers think of a particular build as "upstream 6.13.2 with zfs and realtime patchsets applied" but in reality in any given instance it is actually "6.13.2 -> zfs -> realtime" or "6.13.2 -> realtime -> zfs" depending on which order you cherry-pick/rebase the patches. Both have different git hashes and are properly speaking different things. In pijul it would be "6.13.2 + zfs + realtime" and the order doesn't matter.