pmeunier

12 ms·

61.
by pmeunier 4y ago
Not sure why this is news (and the title is misleading: this is for Libpijul only, not Pijul nor Sanakirja). This has had 0 impact on contributions so far, since "signing" here just means including a patch as a dependency. In 100%
62.
by pmeunier 5y ago
There are so many ways to ask for help about that: - https://pijul.zulipchat.com - https://discourse.pijul.org - https://nest.pijul.com/pijul/pijul/discussions/new if the failure is in
63.
by pmeunier 5y ago
Hint: rerere doesn't always work. It's still guesswork, like the rest of merges/rebases/cherry-picking in Git. This is because looking only at the tips of branches doesn't work, and that's the only thing Git ca
64.
by pmeunier 5y ago
> However, I feel that version control focused on text breaks, Pijul doesn't, by the way, the diff algorithm is customisable. I wrote one industrial application of Pijul that uses spaces as breaks, and semantics-aware breaking is to
65.
by pmeunier 5y ago
You can use branches in Pijul if you want, but you can't use patch commutation in Git.
66.
by pmeunier 5y ago
1. My comment about merges was not on performance. Performance can be considered no correct algorithms, not guesswork (such as 3-way merge). 2. "Git is fast", but when getting into the details, all the operations that are faster i
67.
by pmeunier 5y ago
Practical implications: merges are 100% predictable and deterministic, this isn't always the case in Git, sometimes lines are shuffled around (look for "associativity" in the manual). Also, you can actually cherry-pick. And r
68.
by pmeunier 5y ago
The irony here is that I'm the main author of Pijul, and I don't have a driving license.
69.
by pmeunier 5y ago
It is fast for some operations indeed. But its merge is not always correct (conflicts might reappear, lines might get shuffled around randomly), and rebase and blame aren't super fast (Pijul isn't as optimised for speed as Git, ye
70.
by pmeunier 5y ago
Well, even Gitflow, while not being unreasonable, wastes engineering time. Most devs know it, so at least they don't have to relearn when onboarding, but then their VCS shapes the way they organise their work, when it should be the opp
71.
by pmeunier 5y ago
Thanks, but our problem is different, the datastructure on which all of this is based is memory-mapped, and does need some filesystem and OS cooperation to work well. I haven't tested Pijul on Windows much, and I know that at least at
72.
by pmeunier 5y ago
Storage is not really the issue here. If you merely think about snapshots, all this is fine. The problem come when you merge and rebase your snapshots, possibly solving conflicts in the process. Then none of this snapshot thinking mak
73.
by pmeunier 5y ago
You're not the only one, I too like it. But there comes a time when you want your merges and rebases to work predictably (absolutely never reshuffling your lines randomly), your conflicts to be solved once and for all (without hacks li
74.
by pmeunier 5y ago
> How do you avoid the OS randomly deciding to write a page to disk, per https://db.cs.cmu.edu/mmap-cidr2022/ ? I don't, the OS can flush anything it wants at any time.
75.
by pmeunier 5y ago
> I don't think GP was trying to make a strawman Potential doesn't mean intentional! Sometimes just a lack of precision causes one to argue against a point that was never made (such as "porcelain is the problem").
76.
by pmeunier 5y ago
Thanks! I don't have much experience with Windows, and the backend is quite closely tied to the OS. Is this on plain Windows, or on WSL?
77.
by pmeunier 5y ago
Can't clone it. How many files are there? Also, how did you install Pijul?
78.
by pmeunier 5y ago
How did you install Pijul btw?
79.
by pmeunier 5y ago
The goal of a beta version is to collect feedback, so thanks for that. However, that particular command worked in all the repositories I tried, so I'm really curious about what you are doing.
80.
by pmeunier 5y ago
Interested in seeing that repository, is it public? Never seen that even on massive repositories. `pijul add` times are most of the time comparable with `git add`.
81.
by pmeunier 5y ago
Fully solo: no. Mostly solo: if that means you're in small teams, yes, since you don't need to follow the rigid workflows that prevent large companies from running into Git's problems.
82.
by pmeunier 5y ago
> They solve the problem of "pin a specific version of some external 3rd-party repo" really nicely. My understanding is that they sound to many users like you could do more with them, such as making your repository modular, whe
83.
by pmeunier 5y ago
Context: I'm the main author of Pijul, and also a big fan of Git. This sounds like a potential strawman argument to me, so let's be clear about the complaints you've heard, and my complaints against Git (which, again, I love
84.
by pmeunier 5y ago
Sanakirja has atomic commits, the only hypothesis is that just a few bytes can be written to disk atomically (I don't remember, but certainly at most 8 bytes). All writes are done in atomic transactions.
85.
by pmeunier 5y ago
> Are there other architectural reasons it's particularly suited to pijul? Yes, I originally wrote it because I wanted to fork tables without copying any byte. This is how channels (similar to Git branches) are implemented in Pijul.
86.
by pmeunier 5y ago
Many of these blog posts have been on HN frontpage a number of times already, sometimes for quite a few hours… But alright, never at this rate!
87.
by pmeunier 5y ago
Sanakirja does all those things indeed: Sanakirja doesn't parse anything, doesn't call read(). The answer to all your other questions is yes.
88.
by pmeunier 5y ago
Nothing. However, one could use a central server holding locks on identifiers from the distributed copies. Not mathematically elegant, but fast and convenient in some cases.
89.
by pmeunier 5y ago
That was obviously the first idea, but it isn't really possible. Git is meant to prevent commutation of patches, while Pijul is design to maximise it. Two-way conversion is still a goal, though.
90.
by pmeunier 5y ago
No particular reason, just a mistake in the links. Thanks!

More ›