pmeunier

18 ms·

151.
by pmeunier 6y ago
It is actually defined as "you get the same file contents and directory structure, regardless of the order in which you apply the changes", which is quite good. > But, this seems to require semantic level understanding of the c
152.
by pmeunier 6y ago
Pijul will treat that as a conflict indeed, in particular because it has no way to tell that Alice and Bob meant the same thing when adding that file. A README is a simple example, but what about a module split from a larger module during a
153.
by pmeunier 6y ago
All the arguments you give are based on shortcomings of the tools: Microsoft Word doesn't have version control, Wikipedia stores versions in a database. > But the ultimate goal is to produce a version of the file. The fact that the
154.
by pmeunier 6y ago
I don't think Darcs 3 was even started. Darcs 2 recently solved the exponential merge, but it is now quadratic (which is still exponentially slower than Pijul instead of double-exponentially). I've also been really happy with Darc
155.
by pmeunier 6y ago
> why does pijul decide that the correct merge is only adding the X line after the second instance of AB? It doesn't decide, it only guarantees that the order between lines is preserved in all cases. Also, since you seem to have &qu
156.
by pmeunier 6y ago
It seems we're agreeing indeed! I understood your meant that, but I also thought you meant that snapshots were an implementation detail to simulate diffs. My point is, I don't think they're good at that.
157.
by pmeunier 6y ago
> If I have a 100-line file and on 'main' it changes near the top, but in my 'topic' branch it changes near the bottom, then I can cherry-pick 'topic' onto 'main' and Git will resolve the diff corr
158.
by pmeunier 6y ago
> Snapshots and diffs are different views of the same thing. Not completely: think of conflict resolutions for example. In patch-based systems such as Darcs and Pijul, you don't need a "rerere" command to handle that speci
159.
by pmeunier 6y ago
> I can't agree, because I don't work on diffs, I work on whatever the current state of the file hierarchy is. When I make changes to a file,… This is somewhat contradictory. Of course, everybody works on states. But as you wri
160.
by pmeunier 6y ago
> I'd argue that diffs in the presence of renames aren't natural, and git handles them better than other version control systems. Maybe this is because I designed that part in Pijul, but I disagree. Pijul has renames commute wi
161.
by pmeunier 6y ago
> Patches are commutative (barring conflicts). That isn't quite true, even without conflicts. The same example that shows that Git merge is not associative ( https://pijul.org/manual/why_pijul.html ) can be used
162.
by pmeunier 6y ago
I don't know about ponies, but for snapshots, I disagree: snapshots don't model diffs properly, and many operations in Git are essentially trying to simulate patches: - Merge and rebase both try to "replay" patches. But
163.
by pmeunier 6y ago
This is not inherent to the patch model, just to Darcs' algorithm. Pijul (pijul.org) doesn't have these problems, and is indeed quite fast. The main limitation at the moment is merging very large histories, which has the same comp
164.
by pmeunier 6y ago
That's right, and actually Pijul patches are not actual diffs, they just behave exactly like them for all uses. The main thing I believe is intrinsically superior to Git (I use Pijul a lot) is patch commutation , not just patches. Pij
165.
by pmeunier 6y ago
Actually, I wrote the graphical version of that example (the original authors are cited). I find that the code version is harder to understand. The letters make it much more explicit that Git is really shuffling lines around (I find that sc
166.
by pmeunier 6y ago
You could certainly do that, and this is in fact one of the ways to use Pijul. However, you would completely miss out on the most important novelty of Pijul, which is patch commutation : When we say "Pijul is patch-based", we don
167.
by pmeunier 6y ago
> What's that rebase/cherry-picking craziness? I can only guess what OP had in mind: when you rebase in Git, commits are "replayed" on top of other commits. But there's no way this replay can really work, for two
168.
by pmeunier 6y ago
They're not just diffs indeed, they have a bit more information, see an example there: https://nest.pijul.com/pijul/pijul/changes/XTMYHJZLWWT5I2PJA... First, there are explicit dependencies, and also eac
169.
by pmeunier 6y ago
If you want a better example, see how I manage two different version of my SSH library for Rust, Thrussh: https://nest.pijul.com/pijul/thrussh The problem this is solving is that the Rust ecosystem is in the middle of
170.
by pmeunier 6y ago
In the entire history of Pijul, you probably picked the best example of how to get your reviewer stop being in love with you. That change fixed several hundred errors caused by the removal of a dependency.
171.
by pmeunier 6y ago
> low visibility warnings The versions were called 0.x, each blog post said "this is experimental", and there was even a blinking line on the front page of nest.pijul.com. Maybe we should have printed a notice on the command li
172.
by pmeunier 6y ago
> Then adding "Fix" to another channel will automatically pull in the "dependent change" "pre_Foo" as well, if applicable? Or is a separate "new_Fix" created? I'm not 100% certain of which is
173.
by pmeunier 6y ago
It does allow that, to some extent: by changing the diff algorithm. On thing you can do in a diff algorithm for Pijul (not written yet, but totally possible) is to treat whitespace as their own binary blocks, so that reformatting commutes w
174.
by pmeunier 6y ago
https://www.reddit.com/r/programming/comments/k39td1/pijul_t...
175.
by pmeunier 6y ago
> Please don’t get discouraged by comments pointing out the current limitations of the platform Thanks for the kind message. I totally agree, and didn't take the comment as an offense at all (the reason I reminded the relative youth
176.
by pmeunier 6y ago
Yes! The `pijul git` command allows you to import Pijul repositories by replaying their history. It also works incrementally, meaning that if you already imported a repository, you'll be able to continue new commits. This uses a somewh
177.
by pmeunier 6y ago
> As far as I understand, the main change with respect to Git is that commit hashes don't change depending on previous history, so if you rebase the same change IDs are retained. That is not the main change, merely a by-product. The
178.
by pmeunier 6y ago
We might not have read the same article. > Also, the fact it is written in rust means nothing to me. I'm one of the authors of Pijul, and the author of that post asked me a few questions when preparing that post, and that is address
179.
by pmeunier 6y ago
About your guess on the Pijul hub: nest.pijul.com does something nicer than PRs, which is to attach changes independent from the context, to discussions. See the following discussion, for example: https://nest.pijul.com/piju
180.
by pmeunier 6y ago
This is incredibly useful for a project like Nixpkgs.

More ›