[hsenag]

Even if previous VCSes (edit: other than Darcs) used diffs internally to store changes efficiently, they were still inherently snapshot based.

I think Git's advantage was mainly from using Merkle trees rather than specifically that it was snapshot based.

[adastra22]

To be clear, darcs is neither diff nor snapshot based.

[sunshinerag]

What is it based on then?

[adastra22]

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.

[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).

[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!