3 ms·

So Pijul is patch-based. And not in the boring implementation-sense of storing changes as a series of patches. In the interesting sense that patches can be orde

So Pijul is patch-based. And not in the boring implementation-sense of storing changes as a series of patches. In the interesting sense that patches can be ordered in more arbitrary ways. On the other hand Git is snapshot-based. And Git was built for the Linux Kernel (specifically from the perspective of the lead maintainer). But my impression from the outside is that the Linux Kernel development is very “patch-based”. First of all in the sense of sending patches via email. But also in the sense that these patches can be applied to multiple trees (not just the Linus tree) and different subsystems have to cherry-pick commits (i.e. picking a commit and applying it as a patch, creating a new commit somewhere else). And it seems that people are concerned about tracking what patches are where, what commit (which can correspond to many commits according to cherry-picks) fixes whatever commit. The people behind Patchwork (a tool for maintainers which tracks patch series) is concerned about being able to track patches; the usual `git patch-id`, naming heuristics, etc. does not seem good enough. And as patches go through different contributors and maintainers they accumulate trailers in the form of signed-off-by and things like that. Even non-trailer (not key-value line) changelogs like: `[<initials>: fixed typo/ fixed off by one]`. And if the change is in the code then the patch content changes (not just the commit message). The Git project is also pretty patch-based in its development. Even for those who only cares about the maintainer tree: these patches apply to this other in-flight patch series; this diff here can be applied on top of your pending patch series; this patch series is from our ongoing work at Gitlab (company); I’m resending this patch series that X did three months ago but seemed to have abandoned; etc.

danShumway 3y ago
Genuine question, I have no opinion on this: My understanding is that a big part of the reason that Git is snapshot based is for reliability and for ease of checkout -- being snapshot based means Git doesn't need to replay commits every time you check things out. That likely comes with some downsides (cherry-picking does come to mind, yes), but also seems like some serious upsides, one of the biggest one being that simplicity. It's relatively easy for me to reason about what Git is doing under the hood. I like that I'm seeing that Pijul's patch operations are associative, I like at first glance what I'm seeing it say about merges, but it's not making it clear to me what the downsides are. Is the idea that arbitrary checkouts take longer, but that's generally fine since people don't do them very often? Or am I over-estimating how much complexity/performance costs that building a vcs like this would incur?
- adastra22 3y ago
  There's no reason you can't cache tree snapshots in a pijul/darcs setting. That's just an implementation detail. The difference is more in how a rebase or merge operation works internally, and how essential the particular history is to the current workplace state. Pijul does a better job of recognizing that "A -> B -> C" is the same as "B' -> A' -> C".
  - danShumway 3y ago
    On first download/checkout then I assume I'd download the tree snapshot and it wouldn't replay the patches at all? Local caching would help with repeated checkouts, but most of the time I use Git I'm moving around, so I'm not sure how often I would benefit from that. That also seems like it would lose some verifiability for checkout integrity (?), but maybe that's not a big deal, I'm not sure in practice how much that matters for Git. Repo size also comes to mind on this if snapshots/caches are happening regularly/automatically, since that would mean Pijul is storing both the patches and the end states rather than computing the patches on the fly. But I guess snapshots wouldn't need to be automatic -- I'm not sure how often people actually check out arbitrary commits, maybe you could get away with only caching certain points?
- keybored 3y ago
  The original author sold it as a stupid content tracker. Which in part meant that the implementation was simple. There ain’t a whole lot to the first commit of Git. Some hundred lines which consists of manually preparing a commit by sending the current snapshot to the “cache” (nowadays “index”) which compresses it and then building a commit by specifying the parents and a commit message (like git-commit-tree but I don’t know if that was around back then). Beyond that I don’t know much.

danShumway 3y ago

Genuine question, I have no opinion on this: My understanding is that a big part of the reason that Git is snapshot based is for reliability and for ease of checkout -- being snapshot based means Git doesn't need to replay commits every time you check things out. That likely comes with some downsides (cherry-picking does come to mind, yes), but also seems like some serious upsides, one of the biggest one being that simplicity. It's relatively easy for me to reason about what Git is doing under the hood. I like that I'm seeing that Pijul's patch operations are associative, I like at first glance what I'm seeing it say about merges, but it's not making it clear to me what the downsides are. Is the idea that arbitrary checkouts take longer, but that's generally fine since people don't do them very often? Or am I over-estimating how much complexity/performance costs that building a vcs like this would incur?

adastra22 3y ago
There's no reason you can't cache tree snapshots in a pijul/darcs setting. That's just an implementation detail. The difference is more in how a rebase or merge operation works internally, and how essential the particular history is to the current workplace state. Pijul does a better job of recognizing that "A -> B -> C" is the same as "B' -> A' -> C".
- danShumway 3y ago
  On first download/checkout then I assume I'd download the tree snapshot and it wouldn't replay the patches at all? Local caching would help with repeated checkouts, but most of the time I use Git I'm moving around, so I'm not sure how often I would benefit from that. That also seems like it would lose some verifiability for checkout integrity (?), but maybe that's not a big deal, I'm not sure in practice how much that matters for Git. Repo size also comes to mind on this if snapshots/caches are happening regularly/automatically, since that would mean Pijul is storing both the patches and the end states rather than computing the patches on the fly. But I guess snapshots wouldn't need to be automatic -- I'm not sure how often people actually check out arbitrary commits, maybe you could get away with only caching certain points?
keybored 3y ago
The original author sold it as a stupid content tracker. Which in part meant that the implementation was simple. There ain’t a whole lot to the first commit of Git. Some hundred lines which consists of manually preparing a commit by sending the current snapshot to the “cache” (nowadays “index”) which compresses it and then building a commit by specifying the parents and a commit message (like git-commit-tree but I don’t know if that was around back then). Beyond that I don’t know much.