5 ms·

It seems odd that they boast about being patch based, given that the original advantage of git was that it uses snapshots instead of diffs as previous VCs did.

kgwgk 2y ago
"In our dependency graph you can also see that all our changes concerning the files A and B are totally independent from each other. So I could pull only the changes concerning B from the repository while ignoring the changes regarding A altogether. This is an incredibly powerful mechanism that snapshot based version control systems do not have. Now you can pull in a set of patches and ignore all those that don’t depend on the change you are currently interested in. Other version control systems like git for example call this cherry picking, but compared to darcs they are suffering from some short comings. In those version control system you re-record the patch when you cherry pick it. That means that its whole identity changes, one way in which this manifests is that it will get a different hash. So even though it’s the exact same change the patches are now different. This can become quite annoying when working in a distributed setting, with darcs this is a complete non-issue."
- ltbarcly3 2y ago
  The probability of working software resulting from this operation is approximately 0.
hsenag 2y ago
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 2y ago
  To be clear, darcs is neither diff nor snapshot based.
  - sunshinerag 2y ago
    What is it based on then?
    - hsenag 2y ago
      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 2y ago
        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.
        ltbarcly3 2y ago
        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!
        hsenag 2y ago
        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 2y ago
        It’s the same thing that happens every time you rebase or cherry pick commits in git.
adastra22 2y ago
This isn’t about snapshot vs diff. It is about tree of changes vs. bag of patches.
WolfeReader 2y ago
No. The advantage of Git (and Darcs, Hg, and others) over SVN/TFS is twofold: 1. A much better merging strategy which remembers previous conflict resolutions. This is possible in both diff and snapshot VCS's. 2. Distributed repositories. Instead of storing history in one centralized server, which is prone to several kinds of failure, Git/Darcs/Hg/Fossil etc. all replicate history to each client by default. This makes it very difficult to actually lose code or history, which definitely happened in older centralized systems.
- JTyQZSnP3cQGa8B 2y ago
  > which remembers previous conflict resolutions IMHO this is far from the truth. git is a mess with conflicts and nothing is remembered. When you rebase an old branch a few times, you stumble upon merge conflicts every time you have to rebase that old code. It's really infuriating. I think git became popular for 2 reasons: cheap branches, and Linus Torvalds.
  - reshlo 2y ago
    > The git rerere functionality is a bit of a hidden feature. The name stands for “reuse recorded resolution” and, as the name implies, it allows you to ask Git to remember how you’ve resolved a hunk conflict so that the next time it sees the same conflict, Git can resolve it for you automatically. https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere
  - ltbarcly3 2y ago
    Cheap branches are important. Git is no worse and in most cases far better than any other VCS when it comes to conflicts. If you are getting conflicts over and over you should change your pattern of use to stop causing them, it's quite possible to do.
    - mdaniel 2y ago
      You say that as if using git isn't a team sport. I only have control over my behavior, and that goes double for what happens after $(git pull) or its $(git rebase) friend

kgwgk 2y ago

"In our dependency graph you can also see that all our changes concerning the files A and B are totally independent from each other. So I could pull only the changes concerning B from the repository while ignoring the changes regarding A altogether. This is an incredibly powerful mechanism that snapshot based version control systems do not have. Now you can pull in a set of patches and ignore all those that don’t depend on the change you are currently interested in. Other version control systems like git for example call this cherry picking, but compared to darcs they are suffering from some short comings. In those version control system you re-record the patch when you cherry pick it. That means that its whole identity changes, one way in which this manifests is that it will get a different hash. So even though it’s the exact same change the patches are now different. This can become quite annoying when working in a distributed setting, with darcs this is a complete non-issue."

ltbarcly3 2y ago
The probability of working software resulting from this operation is approximately 0.

hsenag 2y ago

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 2y ago
To be clear, darcs is neither diff nor snapshot based.
- sunshinerag 2y ago
  What is it based on then?
  - hsenag 2y ago
    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 2y ago
      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.
      - ltbarcly3 2y ago
        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!
      - hsenag 2y ago
        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 2y ago
        It’s the same thing that happens every time you rebase or cherry pick commits in git.

adastra22 2y ago

This isn’t about snapshot vs diff. It is about tree of changes vs. bag of patches.

WolfeReader 2y ago

No. The advantage of Git (and Darcs, Hg, and others) over SVN/TFS is twofold: 1. A much better merging strategy which remembers previous conflict resolutions. This is possible in both diff and snapshot VCS's. 2. Distributed repositories. Instead of storing history in one centralized server, which is prone to several kinds of failure, Git/Darcs/Hg/Fossil etc. all replicate history to each client by default. This makes it very difficult to actually lose code or history, which definitely happened in older centralized systems.

JTyQZSnP3cQGa8B 2y ago
> which remembers previous conflict resolutions IMHO this is far from the truth. git is a mess with conflicts and nothing is remembered. When you rebase an old branch a few times, you stumble upon merge conflicts every time you have to rebase that old code. It's really infuriating. I think git became popular for 2 reasons: cheap branches, and Linus Torvalds.
- reshlo 2y ago
  > The git rerere functionality is a bit of a hidden feature. The name stands for “reuse recorded resolution” and, as the name implies, it allows you to ask Git to remember how you’ve resolved a hunk conflict so that the next time it sees the same conflict, Git can resolve it for you automatically. https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere
- ltbarcly3 2y ago
  Cheap branches are important. Git is no worse and in most cases far better than any other VCS when it comes to conflicts. If you are getting conflicts over and over you should change your pattern of use to stop causing them, it's quite possible to do.
  - mdaniel 2y ago
    You say that as if using git isn't a team sport. I only have control over my behavior, and that goes double for what happens after $(git pull) or its $(git rebase) friend