3 ms·

Posts like this add fuel to the fire of my conviction that the future of revision control is Pijul, or something much like it. I can't completely justify the i

Posts like this add fuel to the fire of my conviction that the future of revision control is Pijul, or something much like it. I can't completely justify the intuition here, but this seems like an artificial distinction forced by a snapshot model of a codebase. It's literally about the same patches, but arranged differently to give clarity to the history of the project. So it seems obvious on that level that a system where patches are the fundamental stratum has an advantage there, although I confess that I have yet to use Pijul for a substantial project, so I can't describe in detail how it might make this better. I'm just going off things like how a cherry-pick in Pijul applies the actual change from one branch to the other, rather than duplicating it over. I get frustrated a bit when I think about the gap between the kind of difference a leap forward in revision control could make for our profession, and the amount of resources the Pijul project has to work with. So I'm just putting this out there: MSFT bought GitHub for about 9 billion dollars in 2024 money. Anything which displaces it would be worth more than that. That's a lot of leverage for anyone forward-looking enough to apply it.

travisb 2y ago
While patches and snapshots are duals of each other, patches are generally less easy to reason about and work with, in no small part because compilers and humans work on the snapshot, not the patch. Having worked extensively with patches as the semantic unit via patch(1) and quilt and stgit, I'm very skeptical that a VCS based on patches is actually superior in most circumstances. In this particular case, perhaps it would be helpful to view code reviews as a snapshot where the differences (possibly intra-review revision differences) are highlighted instead of as patches.
- samatman 2y ago
  Roughly, patch(1) has about the same relation to Pijul as RCS has to git. I don't think useful conclusions can be drawn from that experience, basically. As you say, they're duals: but the actual changes need to be modeled as patches to do anything non-trivial with a snapshot. One can build a linear history as a series of snapshots, but applying them to some other timeline can be done with a patch, or with? Nope, it's just patches. My intuition is that architecting the VCS as patches, and making snapshots an interface question, will work better than the other way around. But Pijul is not yet advanced enough in UX terms to really cash out on that guess.

travisb 2y ago

While patches and snapshots are duals of each other, patches are generally less easy to reason about and work with, in no small part because compilers and humans work on the snapshot, not the patch. Having worked extensively with patches as the semantic unit via patch(1) and quilt and stgit, I'm very skeptical that a VCS based on patches is actually superior in most circumstances. In this particular case, perhaps it would be helpful to view code reviews as a snapshot where the differences (possibly intra-review revision differences) are highlighted instead of as patches.

samatman 2y ago
Roughly, patch(1) has about the same relation to Pijul as RCS has to git. I don't think useful conclusions can be drawn from that experience, basically. As you say, they're duals: but the actual changes need to be modeled as patches to do anything non-trivial with a snapshot. One can build a linear history as a series of snapshots, but applying them to some other timeline can be done with a patch, or with? Nope, it's just patches. My intuition is that architecting the VCS as patches, and making snapshots an interface question, will work better than the other way around. But Pijul is not yet advanced enough in UX terms to really cash out on that guess.