pmeunier

5 ms·

1.
by pmeunier 2mo ago
Pijul natively handles monorepos btw, that's the whole point.
2.
by pmeunier 2y ago
Many Rust projects have done cool new stuff. Alacritty is possibly the greatest terminal emulator on the market today. I'm not into cryptocurrencies, but Parity and ZCash are doing cool stuff in that space thanks to Rust. I'm also
3.
by pmeunier 2y ago
This is indeed one of the issues of Pijul, but patch application is extremely fast, which makes it easy in the vast majority of cases (we don't apply patches to files directly, but to an on-purpose on-disk datastructure). We also have
4.
by pmeunier 2y ago
> The only ones I know of are Pijul and Jujitsu which you mentioned. They're both quite new. There are other Git frontends like Jujutsu: Gitless, StackedGit, GitButler, Sapling… Even the idea of "SVN is the next Git" (whic
5.
by pmeunier 2y ago
One of the motivations behind Pijul was to manage custom versions of Nixpkgs while still benefiting from upstream commits. One issue that's hard with Git is that when you also want to contribute multiple changes back, you have: 1. A br
6.
by pmeunier 2y ago
Also, the conflict resolution is just another patch (Pijul patches aren't just regular diffs, they have a lot more information), so should you decide to merge it back upstream after all, you can also cherry-pick the conflict resolution
7.
by pmeunier 2y ago
IMHO there are different ways to design a version control system: 1. The SCSS/Git way, aka the hacker way: look at what we can do with existing stuff, and use that to build something that can do the job. For example if you're on
8.
by pmeunier 3y ago
I've done very little Zig, so this may not be very informed. Indeed we don't use Rust intrinsically that much. With associated type constructors, Rust would be the best language (I know of) to write Pijul in. Without it, most of t
9.
by pmeunier 3y ago
Yes indeed, we would not have started Pijul without the hope that at least theoretically, patch-based designs could be faster than snapshots. "Patch-based is slow" without any other argument is not a very informed claim, Pijul is
10.
by pmeunier 3y ago
Not the same category of tools: Pijul and Fossil have radically different designs, whereas jj is a Git frontend, and Sapling a Mercurial fork.
11.
by pmeunier 3y ago
It's mostly about Rust adding lots of features I am not interested in, and not adding the ones I need for the project. Sanakirja was hard to write in Rust, not a single concept of the language matched what I needed, in the end I had to
12.
by pmeunier 3y ago
In Pijul the head is a CRDT. Having used it for years to develop itself, I can definitely imagine!
13.
by pmeunier 3y ago
Pijul handles binary files natively, using a number of mathematical tricks removing the need for extra layers (layers like LFS). If you're interested come talk to us!
14.
by pmeunier 3y ago
At the time we thought our tools were good, and really meant it. Now it's different, we think our new tools are good, and we really mean it. But it's different.
15.
by pmeunier 3y ago
Wait, nobody in the Pijul team brags about being in Rust. If Pijul were written today it would probably be in Zig, for many reasons.
16.
by pmeunier 3y ago
I can answer that question, as both the author of Pijul and as someone most Rust zealots usually don't like very much. Nothing magical in Rust, at the time it was the only language that worked seamlessly on Windows and Linux, and made
17.
by pmeunier 3y ago
You're describing working on your own single-author project, in which case there is indeed little difference (Pijul has less tooling). In practice on actual real world cases, there are lots of differences when you start working with ot
18.
by pmeunier 3y ago
> Git to Pijul is a much smaller change, it is much more difficult to justify. Having used both extensively, I don't think this is true at all. I don't see as much difference between SVN and Git, as I see between these two and
19.
by pmeunier 3y ago
> why would you (or the authors of Pijul) care about this extremely rare case? I'm the main author, and my answer is: because it allowed to to model with great mathematical rigor what conflicts are, how to represent them and how to
20.
by pmeunier 3y ago
This question is really deep. The "distributed" nature of Git makes some things easier than SVN: you can scale to large teams, work offline, split a repo into independent subrepos for a while (managed via branches; good luck with
21.
by pmeunier 3y ago
First, thanks for the patient and kind advice. This is so rare I didn't even know you were allowed to talk like that online. > I think you should try to let go of the idea of "evolving the license" of an open source projec
22.
by pmeunier 3y ago
we have `pijul diff -sU`, which is similar to `git status`. Also, feel free to contribute!
23.
by pmeunier 3y ago
By not being a CI tool, nor claiming to solve such Turing-complete problems. Pijul has a theory of textual changes, but indeed doesn't care at all about what you write in your files: that's your problem!
24.
by pmeunier 3y ago
Oops, don't look at what we do! These repos have been used for dogfooding and bootstrapping extensively, they have the worst structures and aren't good examples of nice, clean workflows. The tool isn't really "experiment
25.
by pmeunier 3y ago
The key insight of Pijul is to be the smallest generalisation of a file that is a CRDT with insertions and deletions of bytes as its two operations, where "smallest" and "file" are meant in a specific sense. The main thi
26.
by pmeunier 3y ago
This problem was never reported a single time on our Zulip or by email, but I'm glad you asked, because this choice wasn't obvious: - The main reason the CLA is there is that earlier versions of Libpijul saw lots of online argumen
27.
by pmeunier 3y ago
> When the contents has a conflict, git and pijul behave similarly. Not really: Pijul can record a conflict resolution as a patch, and apply it in a different context. Also, the conflict doesn't "come back", so you don&#x
28.
by pmeunier 3y ago
> the notion of commutativity here is very weak and counterintuitive; it only seems to cover the applicability of an auto-merge heuristic This is completely false: in Pijul, any patches that could have been produced independently can be
29.
by pmeunier 3y ago
As probably the person in the entire world who has been wanting this for the longest, thank you! Please share on Pijul's Zulip, and ask for any help you may need.
30.
by pmeunier 3y ago
`pijul fork`. There you go, I wrote an entire key-value store just to get that to work. It turned out to be faster than all others, but that wasn't intentional.

More ›