I am vibecoding a elixir/phoenix agent dashboard to manually & closely review the coding agent plans and code patches for my day job. I am at a stage where I can I use portal to work on the portal and my day job.
I have not yet figured out a way to live reload the dashboard itself after a feature addition or a bug fix. :-(
> Git stores the repository changes as a series of snapshots. That means that every time we commit changes it keeps a new version of every file that changed so the size of the repo could grow quickly.
The very first statement in the gtihub page seems to ignore Git packfiles completely for the sake of argument.
Their wording is indeed bad, and does not convey at all what they wanted to convey.
Git stores patches to reduce disk size, and does so very effectively. However the same exact patch, applied to a different head has a different commit id. That commit id is a snapshot, even if it is stored as a patch.
Pijul, that same patch applied to different heads, will always have the same hash. This has some advantages that is deeper in their documentation.
Basically, you can cherry-pick changes (patches) from someone else, and then later merge their entire branch, but not conflict on the patches you already imported. Having dealt with this with git, I can see the appeal.
> That commit id is a snapshot, even if it is stored as a patch.
I agree with your argument, but Git does store "blobs" only (plus "trees"), and never patches. When you can ask it to show you a diff between two snapshots, Git computes the diff on the fly.
"What is cool is that although the objects on disk before you ran the gc were collectively about 8K in size, the new packfile is only 4K. How does Git do this? When Git packs objects, it looks for files that are named and sized similarly, and stores just the deltas from one version of the file to the next."
You are right that this isn't the thing that's presented to the user as "git diff". The model that Git uses is that each commit has each file at that version, but it uses an optimization (the packfile) to make sure that doesn't take up more disk space than necessary.
Git does store deltas between files to reduce space. Every so often it stores a full copy of the file to improve performance.
Perhapps patch was the wrong word, but a delta and a patch are the same in my mind.
I am sure everything, including pijul, does diff generation on the fly of the full files at different points. It would be faster than figuring out the difference of patches alone.
A packfile delta in Git is arguably an implementation detail — a compression technique — not part of the data model.
Git's data model consists of commits, trees, refs and so on. Not patches. You can implement Git without deltas and it will work the same. But in Pijul, the patch is the data model.
The whole idea of Pijul (and the project it was inspired by, Darcs) is that if you think of patches as units of data that fit together using a kind of formalism (usually called the "theory of patches"), you end up with a very powerful system that makes certain things — solving conflicts, figuring out what commits a single commit depend on — super easy. The patch isn't an implementation detail, because you cannot reimplement Pijul without it.
By the way, that guide is not from the authors of Pijul, even though as an author myself, I'm happy to see people understand it, use it and explain it.
I believe a more gentle and constructive way of discussing this is by starting a discussion on their page [1].
I have not yet figured out a way to live reload the dashboard itself after a feature addition or a bug fix. :-(