3 ms·

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 ch

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.

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.