Is anyone tracking other projects that aim to replace or at least repudiate git?

He’s definitely helping me to believe that using an immutable database rather than git is not only legitimate but actually needed

Doesn't fossil offer that? All artifacts in Fossil are immutable and changes are accretive.

There is a very strong argument for deletion of commits (i.e., oops, I've put my super-secret-key-that-will-destroy-the-entire-infrastructure-into-the-repo-and-pushed)

And there may be a legal reason for deletion too.

It's covered in Section 2.7 here:

what's he suggesting (I'm on a uk train atm - video not plausible)? that the commit DAG be stored in a db, like fossil? or an immutable db like kafka+flink/streams or xtdb?

I don't understand the implementation details of Pijul, but basically it is an implementation of the theory of patches, same as the Darcs VCS is/was built on. He built a new database to solve the performance problems with Darcs, which means Pijul is viable for large projects. This is an older post on his experience building that db: https://pijul.org/posts/2021-02-06-rethinking-sanakirja/ Personally I think Pijul is very interesting just because it relies on the theory of patches, and I've wanted that since I tried Darcs a long time ago.

I have started using Pijul for a couple of personal projects just to see how it works, but obviously that does not make a good test for a DVCS, since I have noone to collaborate with.

As an old Darcs fan, I’m happy to see Pijul getting attention.

having never used fossil, darcs or pijul, what do they do better than git - in what situations will your life be easier or improved ? i've gotten quite used to git, and the only git pain i've had in recent memory has been related to conflict resolutions from merging trunk onto a long-lived feature-branch getting lost when rebasing that feature-branch (which was easily solved by not rebasing the feature-branch, since we were squash-merging feature branches back to trunk anyway) ... but i get the feeling i might have gotten a bad case of stockholm syndrome ...

I'm intrigued by fossil. I like the idea of having a bug tracker/wiki/forum in one binary

I would love to give it a try

his main objection is that git is based on a bunch of hacks, CRDTs are not scalable and that one can instead use category theory as a principled basis for tracking changes. His hosted implementation uses Rust/WASM on CloudFlare workers with memory addresses mapped to object storage offsets. And there's a ton of details below that obvs.

> i've gotten quite used to git, and the only git pain i've had in recent memory has been related to conflict resolutions from merging trunk onto a long-lived feature-branch getting lost when rebasing that feature-branch (which was easily solved by not rebasing the feature-branch, since we were squash-merging feature branches back to trunk anyway) ... but i get the feeling i might have gotten a bad case of stockholm syndrome ... The main sell of a VCS built on a sound theory of patches is that when you solve a conflict it is solved for good. The difference between pijul/darcs and git is that git is a collection of snapshots of the files in the repository, while pijul treats the repository as a collection of patches that might depend on other patches. So while a git sha represents a snapshot of your code base, a pijul change ref represents a patch. As I understand it, this means that in git the state of the repo is directly encoded in each commit, at the cost of difficult merges; while in pijul the state of the repo has to be computed based on the stored patches, but with the benefit that merges and conflicts are much simpler.

In pijul you can unrecord a patch even though it is not at the head of you change log, and any patches depending on that patch will also be unrecorded. This leaves the changes in your working tree ready to be recorded again in smaller pieces or dropped partially/entirely. Repository state does not depend on patches being applied in any particular order (outside their dependency order of course).

(commenting on this discussion, not the video, as I haven't seen it yet) I'm not convinced that what you guys are mentioning is that much better than git, but I am also firmly entrenched, even with all of git's weirdness.

I think it is way better than git, but git has come to mean so much more than just git the VCS. The entire ecosystem around git (github, gitlab, etc.) is just so good at this point, and any new or niche VCS won't have that (yet). At this point I am experimenting with using Pijul as my VCS, but committing snapshots to git for integration with my CI/CD pipelines. At this point Pijul is "just" a very good VCS, the tooling around it is yet to come.

Yeah, git is just so entrenched! It's all the tooling around it that makes working with it pretty straight-forward. It's good enough for the majority of what I need a VCS for. Heck, I remember using CVS starting out.... 🙂

no

😛

😭

(commenting on the discussion, not the video). As an old Darcs fan, I have not heard of Pijul; so thanks for that! > Is git the final word on version control? Just wanted to throw a little fresh wood into the 🔥. I think the stuff Unison language is trying with mapping functions and dependencies to immutable content-based hashing databases and DAGs is also a different kind of answer to the future of version control. It rephrases the question from how to best merge/diff/distribute bytes to how to best merge/diff/distribute functions.

I think we need to highlight the real tragedy of this thread > I'm on a uk train @U0524B4UW I feel your pain

also @U0P0TMEFJ the train's coffee machine was broken and the snack bar would only accept cash. it was #firstworldproblems awful

Pijul is embryonic, running on fumes and GitHub has itself in the autocomplete and was bought for $7.5bn. It’s good enough and is deeply entrenched in most dev lives. I just think we should be open to the fact that it’s not the end.

I think there's an argument to be made that git's snapshot model is correct and it's the job of a diffing algorithm to help transition between the snapshots. The fact that these stories of bum merges are much less often than they were when we used cvs or svn suggests that the dumb text merge that got uses is mostly good enough? Something like Clojure with it's regular explicit tree structure should be applicable to a syntax aware merge algorithm. But I've never needed one enough to actually try and write it.

this discussion is causing me to question my understanding : what does git actually store in its commit files ? i always thought it stored a patch + metadata, and that the idea of a commit-sha identifying a snapshot is essentially just pointing out that a snapshot and a node in a DAG of patches are duals of each other (similarly to a kafka changelog offset and a corresponding db table snapshot). am i wrong - does git store something other than patches in commits ?

No, git snapshots are blobs of content + metadata (directories, parents, file metadata, etc). If two files have the same content (irrespective of time) they are essentially the same blob with the same object-id. Diff is a materialized view. This looks like a good high-level overview: https://github.blog/2020-12-17-commits-are-snapshots-not-diffs/

ah, nice - i completely failed to find that yday 🙂 - my git internal model is now suitably updated

Beautiful! Love the angles. ☁️ uu u uuu uu ☁️ u u ☁️ u u ☁️ \ \\ v ⛰️ v ⛰️ vv /

Indeed, one of the most spectacular view I’ve seen in person. It was rather early morning hike and was too cold to take a camera out of the bag 😅

Good donuts in Dundee 😄