2 ms·

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 human

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.