8 ms·

Pijul – The Mathematically Sound Version Control System Written in Rust

92 points by initialcommit 6y ago

junon 6y ago
Just reading the "abstract", this sounds way more complicated than anyone needs a VCS to be. I also question the "mathematically sound" bit - the "commutative changes/diff" thing sounds really far fetched. Also, the fact it is written in rust means nothing to me. The whole "but rust doesn't segfault!" thing is, and has always been, a ridiculous reason why rust is somehow inherently better suited for such projects. The article keeps leaning on that fact as though it makes the project superior somehow, but it just feels like grandstanding. The architecture section is just buzzwords. It doesn't explain the technical aspects, it doesn't allow me to understand the system, and then I'm immediately dropped into "how to use the CLI". But wait, you haven't sold me yet. This was painful to read.
- jedisct1 6y ago
  Yes, but it is written in Rust.
- JoeCamel 6y ago
  I don't read it like that at all. Rust is mentioned only once. Nevertheless I do care if a tool I am considering to use is written in JavaScript, Rust or some esoteric language. It means a lot, not only for "safety" which is not important to you that much, but also for maintainability, community, and the future of the project. Of course, what triggers you probably is mentioning Rust in the title of the post. Still hard to imagine being so annoyed by it–if authors thinks it's important or it will grab attention, why not use it...
- whateveracct 6y ago
  > Just reading the "abstract", this sounds way more complicated than anyone needs a VCS to be. I also question the "mathematically sound" bit - the "commutative changes/diff" thing sounds really far fetched. Care to say anything more quantitative and less feel-y? Because you're refuting pretty much the entire premise of pijul (which clearly exists, works, and has been somewhat rigorously designed) with nothing but adjectives. So having a concrete counterpoint would be helpful because pijul is just sitting there with very concrete counterpoints to your entire comment :)
- mhh__ 6y ago
  Honestly as long as it's not written in JavaScript (I like not having npm and node on my machine) or C (not abstract enough) I'm happy to use it. For small tool at least.
- 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 addressed there: https://initialcommit.com/blog/pijul-creator https://initialcommit.com/blog/pijul-creator (see "Why did you choose to write Pijul in Rust?"). > It doesn't explain the technical aspects, it doesn't allow me to understand the system You can have plenty of that there: https://pijul.org/manual/theory.html https://pijul.org/manual/theory.html. > This was painful to read. I strongly disagree. Explaining the goals of this project isn't always easy, because both large complex projects and complete beginners can benefit from using a rigorous mathematical modeling. I guess this blog post leans more towards the "beginners" side, whereas the "Theory" page linked above would be more appealing to power users. Both are useful and important, they just appeal to different people.
- nilkn 6y ago
  The Rust part I think is meaningful. It means we can (with reasonable probability) expect the software to be fast and lightweight in terms of memory usage, and it means it’s probably a lot easier for new contributors to jump in than an equivalent C or C++ codebase. That last bit is about a lot more than memory safety. Rust is basically designed from the ground up to make it relatively easy to onboard a new engineer safely onto a project in comparison to legacy systems languages.
  - jedisct1 6y ago
    And abandoned quite quickly, like most Rust projects.
    - nilkn 6y ago
      > And abandoned quite quickly, like most projects. Amended your statement slightly. If anything, there's a fairly high incidence of successful projects coming out of the Rust world.
arka2147483647 6y ago
It would be nice if the authors could provide practical examples of their features, instead of a theoretical talk about mathematical soundness. Ie; how does this make my life, as a programmer, easier?
- gjulianm 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. Personally I've never had an issue with conflicts after cherry-picking, if Git sees the same change in two branches it manages it correctly most of the time. Furthermore, I like that commit ID changes when previous history is changed: a commit ID refers to a certain state of the repository. I don't like that two repositories in different states could have the same commit ID.
  - 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. There are many changes: - Perhaps one of the most crucial differences is that Pijul uses a rigorous merge algorithm, and doesn't run into the bad merge examples described in [1]. Note that the situation described there happens without any conflict, and doesn't tell anything to the user. - Changes that could be written independently commute, meaning that they can be pushed independently. You don't have to worry about isolating them on feature branches, which can save time if you (like me) work on many features at the same time. - Rebase and Merge are the same operation in Pijul, and happens automatically. Conflicts happen between changes, and conflict resolutions are recorded as changes, so you don't need any `git rerere` (which essentially guesses what to do), since conflict resolutions work even in a different context. - Everything is invertible! You can even remove an old change from a channel if you like, as long as other changes don't depend on it. > I don't like that two repositories in different states could have the same commit ID. That never happens in Pijul. Changes are not commits, they're diffs between commits. And states have identifiers too, they're just more subtle: if you have two changes A and B, Pijul can apply them in any order without changing the result (so why change the commit id?). In Pijul, if you run `pijul log --state`, on "A, then B" and "B, then A", you will get the same state id. [1] https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html
Jyaif 6y ago
"One of Pijul's goals is to minimize the number of commands" Shut up and take my money.
oxinabox 6y ago
I really want to use Pijul, but programming is a team sport. And especially open source. The Pijul equivelent of GitHub is Nest. It's just not there yet. Firstly, there are basically no potential colaborators for the areas i work on. Secondly, it is much less mature ass a platform. In 5 minutes i couldn't find any way to "browse repositories" inn any sense, to discover what is out there. Discussions are not fleshed out as a issue tracker (no tags for a start), though that could be dealt with by using a 3rd party issue tracker. Pijul's whole setup seems like it would solve a bunch of problems I have with git. 1. that a commit maintains its own identity when cherrypicked onto another branch, and its intrinstically linked. Vs in Git where it is a unrelated (but identical) set of changed. 2. the whole merge/rebase dichotomy. In git most people try annd avoid merging the main branch into the feature branch, because it leads to messy history and hard to understand where changes come from, and prefer to instead do rebase. But for a merge you only need to resolve conflicts once. For a rebase you need to resolve them potentially again and again even if those conflicts never would matter to the final version (e.g. if the file that is conflicting has been deleted before HEAD) But Pijul doesn't have seperate merge and rebase because changed in Pijul commute. Which is a mind twise of an idea. But they say they solved it, so nice.
- wocram 6y ago
  You can use git rerere to avoid the repeated rebase conflicts.
  - kelnos 6y ago
    As an obsessive rebaser, in practice I've found that rerere very rarely kicks in during a rebaser unless the conflict looks exactly the same across commit applications, which is rarely the case.
- auggierose 6y ago
  Programming can be a team sport, but doesn't have to be. It doesn't even have to be a sport.
- pmeunier 6y ago
  > Firstly, there are basically no potential colaborators for the areas i work on That's correct. On the other hand, this is a network effect, and the Nest, in its current incarnation, is only 3 weeks old. It's getting better every day, though. The two main features I'm working on at the moment are: - CI/CD. This is almost ready to go, it is "sort of" working. One issue that I fixed recently is that Pijul versions are tricky to compute: change A, followed by B, is the same state (guaranteed by design) as B, followed by A. Our version identifiers handle that now (try `pijul log --state`). - Social features, like discoverability, recommendation of collaborations. We're really just getting started at this, and figuring out what works best. I should add that until two weeks ago, the Nest would stop accepting connections at random times, or crash. It's much more stable now, and we can finally think of adding features. > Secondly, it is much less mature ass a platform There are tags for issues. You can configure them in the "Admin" page of your repositories. They're not used very much for Pijul itself, because most issues so far have been closed within minutes or hours after their creation. > Which is a mind twise of an idea. But they say they solved it, so nice. As one of the authors, I can tell you it wasn't easy to get everything to work together, especially for conflicts. But the theory is clear and sound now (and I have good confidence that the implementation is, too): any two patches that could have been created independently can be pushed to a remote repository independently from each other.
kadoban 6y ago
Is there any hope in Pijul of _any_ kind of interoperability with git at all? Back when there used to be some projects still stuck on svn that I wanted to work on, I was able to use git locally and just kind of "publish" via svn when I was done. Would anything like that be possible? That'd be the killer thing for me to be able to give Pijul a real try.
- onetimertwo 6y ago
  This.
- 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 somewhat naive way of doing things, and can take a very long time on large repositories. One other way of doing it would be to add an "initial change" explicitly saying "I'm coming from Git commit number #SHA1HASH".
  - kadoban 6y ago
    Thanks! I'll definitely give that a try, just looking at the docs real quick it sounds pretty doable. I can think of at least twice in the last month that I _think_ this would have saved me some effort, be interesting to give it a go. Cheers!
- gnufx 6y ago
  For what it's worth, you can do that with Darcs import/export. I've kept parallel git and hg repos synced that way with a cron job; it could be done with a hook, but that slowed down pushes too much in my case. (Doing that basically assumes one branch, i.e. linear development in Darcs.)
notmars 6y ago
Shall we talk about the name? Or does nobody care about the impact of subconscious bias in adoption of dev tools and ai should shut up ? :-)
- kroltan 6y ago
  What about it? Searching for "pijul -vcs" shows images of birds, which is reasonable?
  - notmars 6y ago
    1- I’m not sure how to pronounce it (maybe it s just me), ‘j’ has a lot of depth consonent-wise (https://en.m.wikipedia.org/wiki/Voiced_palatal_approximant https://en.m.wikipedia.org/wiki/Voiced_palatal_approximant) 2- what’s the story behind it (strong believer in the importance of symbols and what they attach to) 3- what is it supposed to make me think of? A pidgeon? So it’s everywhere and defecate randomly on people? I must also postface: I understand it’s a spanish word meant to evoke a bird (what for?) and maybe I’m the only one that believes that simple evocative name change anything, but hey, here you are in that thread :-p
    - dan-robertson 6y ago
      For 1, the name of the bird is Spanish so you could pronounce the j as https://en.m.wikipedia.org/wiki/Voiceless_velar_fricative https://en.m.wikipedia.org/wiki/Voiceless_velar_fricative Alternatively you could just read it without that knowledge and pronounce it however you like. As far as I’m aware it follows a theme of other bird names for other parts of the project. It seems fine compared to eg mercurial (if you spend a lot of time with it you go mad?) or git (the word you mutter under your breath as you use it?)
- songqin 6y ago
  what's wrong with the name?
- gnusty_gnurc 6y ago
  Yea I was searching to see if anyone else would mention this, especially seeing the uproar about GIMP, etc. I don’t care about the naming dispute stuff, but this is comically close to pee-hole.
Technically 6y ago
Does this allow for semantic, non-text diffing? This would allow for code formats without syntax errors (i.e. storing the valid AST in binary as separate, likely structured in binary, from the editor representation). Diffs would then be truly semantic, representing semantic refactorings (e.g. "extract method to function", "rename symbol") at the patch level. you could easily then query "when did this variable show up" even post-refactor where the variable moves modules. Sure this has its limits but it'd push the tooling to levels virtually impossible to automate with text-based code now. A man can dream!
- 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 with other changes.
  - yencabulator 6y ago
    By that logic, so does Git (disregarding fundamental Git vs Pijul differences).
- gnufx 6y ago
  Darcs has "replace" for that, the only other patch type that's been implemented for it as far as I know. I think Toolpack provided that for Fortran in the 1980s, but I don't remember for sure whether its version control was AST-based latterly (and, of course, it wasn't networked, let alone distributed).
jgalt212 6y ago
This write up is very kind to Git (vis a vis one of it pros): > Intuitive method and interface for version tracking
- pmeunier 6y ago
  https://www.reddit.com/r/programming/comments/k39td1/pijul_the_mathematically_sound_version_control/ge1w28y/?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/programming/comments/k39td1/pijul_t...
gnufx 6y ago
I asked before, but didn't get an answer. Darcs is criticized for lack of soundness and potential exponential merge complexity -- which I'm not sure I've actually run into -- but that's Darcs2. I haven't actually followed along, but I thought the development Darcs3 is an answer. This may not be the place to ask, but can anyone compare the new Pijul and Darcs3?
nieve 6y ago
With this latest release does Pijul now have an extensive test harness to prevent the corruption & data loss in repositories that people have been experiencing for years? I know pre-1.0 versions had low visibility warnings that you shouldn't actually use Pijul for any code you cared about, but I'd assume that is no longer true for a 1.0 version. I've been very interested as an on-again off-again Darcs user, but when people were reporting that it destroyed their data it was a kind of scary step to take.
- 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 line tool itself ;-) More seriously, one major issue with the 0.x versions was that bad performance meant we couldn't really test it massively. But now we can, and actually one of my first tests was to try and import the history of Nixpkgs, and run massive checks for data loss after every operation. It works now.
  - speedkills 6y ago
    As scalability was one of the design goals. are there any comparisons of performance with huge repos?

92 points by initialcommit 6y ago

Just reading the "abstract", this sounds way more complicated than anyone needs a VCS to be. I also question the "mathematically sound" bit - the "commutative changes/diff" thing sounds really far fetched. Also, the fact it is written in rust means nothing to me. The whole "but rust doesn't segfault!" thing is, and has always been, a ridiculous reason why rust is somehow inherently better suited for such projects. The article keeps leaning on that fact as though it makes the project superior somehow, but it just feels like grandstanding. The architecture section is just buzzwords. It doesn't explain the technical aspects, it doesn't allow me to understand the system, and then I'm immediately dropped into "how to use the CLI". But wait, you haven't sold me yet. This was painful to read.

jedisct1 6y ago
Yes, but it is written in Rust.
JoeCamel 6y ago
I don't read it like that at all. Rust is mentioned only once. Nevertheless I do care if a tool I am considering to use is written in JavaScript, Rust or some esoteric language. It means a lot, not only for "safety" which is not important to you that much, but also for maintainability, community, and the future of the project. Of course, what triggers you probably is mentioning Rust in the title of the post. Still hard to imagine being so annoyed by it–if authors thinks it's important or it will grab attention, why not use it...
whateveracct 6y ago
> Just reading the "abstract", this sounds way more complicated than anyone needs a VCS to be. I also question the "mathematically sound" bit - the "commutative changes/diff" thing sounds really far fetched. Care to say anything more quantitative and less feel-y? Because you're refuting pretty much the entire premise of pijul (which clearly exists, works, and has been somewhat rigorously designed) with nothing but adjectives. So having a concrete counterpoint would be helpful because pijul is just sitting there with very concrete counterpoints to your entire comment :)
mhh__ 6y ago
Honestly as long as it's not written in JavaScript (I like not having npm and node on my machine) or C (not abstract enough) I'm happy to use it. For small tool at least.
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 addressed there: https://initialcommit.com/blog/pijul-creator https://initialcommit.com/blog/pijul-creator (see "Why did you choose to write Pijul in Rust?"). > It doesn't explain the technical aspects, it doesn't allow me to understand the system You can have plenty of that there: https://pijul.org/manual/theory.html https://pijul.org/manual/theory.html. > This was painful to read. I strongly disagree. Explaining the goals of this project isn't always easy, because both large complex projects and complete beginners can benefit from using a rigorous mathematical modeling. I guess this blog post leans more towards the "beginners" side, whereas the "Theory" page linked above would be more appealing to power users. Both are useful and important, they just appeal to different people.
nilkn 6y ago
The Rust part I think is meaningful. It means we can (with reasonable probability) expect the software to be fast and lightweight in terms of memory usage, and it means it’s probably a lot easier for new contributors to jump in than an equivalent C or C++ codebase. That last bit is about a lot more than memory safety. Rust is basically designed from the ground up to make it relatively easy to onboard a new engineer safely onto a project in comparison to legacy systems languages.
- jedisct1 6y ago
  And abandoned quite quickly, like most Rust projects.
  - nilkn 6y ago
    > And abandoned quite quickly, like most projects. Amended your statement slightly. If anything, there's a fairly high incidence of successful projects coming out of the Rust world.

arka2147483647 6y ago

It would be nice if the authors could provide practical examples of their features, instead of a theoretical talk about mathematical soundness. Ie; how does this make my life, as a programmer, easier?

gjulianm 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. Personally I've never had an issue with conflicts after cherry-picking, if Git sees the same change in two branches it manages it correctly most of the time. Furthermore, I like that commit ID changes when previous history is changed: a commit ID refers to a certain state of the repository. I don't like that two repositories in different states could have the same commit ID.
- 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. There are many changes: - Perhaps one of the most crucial differences is that Pijul uses a rigorous merge algorithm, and doesn't run into the bad merge examples described in [1]. Note that the situation described there happens without any conflict, and doesn't tell anything to the user. - Changes that could be written independently commute, meaning that they can be pushed independently. You don't have to worry about isolating them on feature branches, which can save time if you (like me) work on many features at the same time. - Rebase and Merge are the same operation in Pijul, and happens automatically. Conflicts happen between changes, and conflict resolutions are recorded as changes, so you don't need any `git rerere` (which essentially guesses what to do), since conflict resolutions work even in a different context. - Everything is invertible! You can even remove an old change from a channel if you like, as long as other changes don't depend on it. > I don't like that two repositories in different states could have the same commit ID. That never happens in Pijul. Changes are not commits, they're diffs between commits. And states have identifiers too, they're just more subtle: if you have two changes A and B, Pijul can apply them in any order without changing the result (so why change the commit id?). In Pijul, if you run `pijul log --state`, on "A, then B" and "B, then A", you will get the same state id. [1] https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html

Jyaif 6y ago

"One of Pijul's goals is to minimize the number of commands" Shut up and take my money.

oxinabox 6y ago

I really want to use Pijul, but programming is a team sport. And especially open source. The Pijul equivelent of GitHub is Nest. It's just not there yet. Firstly, there are basically no potential colaborators for the areas i work on. Secondly, it is much less mature ass a platform. In 5 minutes i couldn't find any way to "browse repositories" inn any sense, to discover what is out there. Discussions are not fleshed out as a issue tracker (no tags for a start), though that could be dealt with by using a 3rd party issue tracker. Pijul's whole setup seems like it would solve a bunch of problems I have with git. 1. that a commit maintains its own identity when cherrypicked onto another branch, and its intrinstically linked. Vs in Git where it is a unrelated (but identical) set of changed. 2. the whole merge/rebase dichotomy. In git most people try annd avoid merging the main branch into the feature branch, because it leads to messy history and hard to understand where changes come from, and prefer to instead do rebase. But for a merge you only need to resolve conflicts once. For a rebase you need to resolve them potentially again and again even if those conflicts never would matter to the final version (e.g. if the file that is conflicting has been deleted before HEAD) But Pijul doesn't have seperate merge and rebase because changed in Pijul commute. Which is a mind twise of an idea. But they say they solved it, so nice.

wocram 6y ago
You can use git rerere to avoid the repeated rebase conflicts.
- kelnos 6y ago
  As an obsessive rebaser, in practice I've found that rerere very rarely kicks in during a rebaser unless the conflict looks exactly the same across commit applications, which is rarely the case.
auggierose 6y ago
Programming can be a team sport, but doesn't have to be. It doesn't even have to be a sport.
pmeunier 6y ago
> Firstly, there are basically no potential colaborators for the areas i work on That's correct. On the other hand, this is a network effect, and the Nest, in its current incarnation, is only 3 weeks old. It's getting better every day, though. The two main features I'm working on at the moment are: - CI/CD. This is almost ready to go, it is "sort of" working. One issue that I fixed recently is that Pijul versions are tricky to compute: change A, followed by B, is the same state (guaranteed by design) as B, followed by A. Our version identifiers handle that now (try `pijul log --state`). - Social features, like discoverability, recommendation of collaborations. We're really just getting started at this, and figuring out what works best. I should add that until two weeks ago, the Nest would stop accepting connections at random times, or crash. It's much more stable now, and we can finally think of adding features. > Secondly, it is much less mature ass a platform There are tags for issues. You can configure them in the "Admin" page of your repositories. They're not used very much for Pijul itself, because most issues so far have been closed within minutes or hours after their creation. > Which is a mind twise of an idea. But they say they solved it, so nice. As one of the authors, I can tell you it wasn't easy to get everything to work together, especially for conflicts. But the theory is clear and sound now (and I have good confidence that the implementation is, too): any two patches that could have been created independently can be pushed to a remote repository independently from each other.

kadoban 6y ago

Is there any hope in Pijul of _any_ kind of interoperability with git at all? Back when there used to be some projects still stuck on svn that I wanted to work on, I was able to use git locally and just kind of "publish" via svn when I was done. Would anything like that be possible? That'd be the killer thing for me to be able to give Pijul a real try.

onetimertwo 6y ago
This.
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 somewhat naive way of doing things, and can take a very long time on large repositories. One other way of doing it would be to add an "initial change" explicitly saying "I'm coming from Git commit number #SHA1HASH".
- kadoban 6y ago
  Thanks! I'll definitely give that a try, just looking at the docs real quick it sounds pretty doable. I can think of at least twice in the last month that I _think_ this would have saved me some effort, be interesting to give it a go. Cheers!
gnufx 6y ago
For what it's worth, you can do that with Darcs import/export. I've kept parallel git and hg repos synced that way with a cron job; it could be done with a hook, but that slowed down pushes too much in my case. (Doing that basically assumes one branch, i.e. linear development in Darcs.)

notmars 6y ago

Shall we talk about the name? Or does nobody care about the impact of subconscious bias in adoption of dev tools and ai should shut up ? :-)

kroltan 6y ago
What about it? Searching for "pijul -vcs" shows images of birds, which is reasonable?
- notmars 6y ago
  1- I’m not sure how to pronounce it (maybe it s just me), ‘j’ has a lot of depth consonent-wise (https://en.m.wikipedia.org/wiki/Voiced_palatal_approximant https://en.m.wikipedia.org/wiki/Voiced_palatal_approximant) 2- what’s the story behind it (strong believer in the importance of symbols and what they attach to) 3- what is it supposed to make me think of? A pidgeon? So it’s everywhere and defecate randomly on people? I must also postface: I understand it’s a spanish word meant to evoke a bird (what for?) and maybe I’m the only one that believes that simple evocative name change anything, but hey, here you are in that thread :-p
  - dan-robertson 6y ago
    For 1, the name of the bird is Spanish so you could pronounce the j as https://en.m.wikipedia.org/wiki/Voiceless_velar_fricative https://en.m.wikipedia.org/wiki/Voiceless_velar_fricative Alternatively you could just read it without that knowledge and pronounce it however you like. As far as I’m aware it follows a theme of other bird names for other parts of the project. It seems fine compared to eg mercurial (if you spend a lot of time with it you go mad?) or git (the word you mutter under your breath as you use it?)
songqin 6y ago
what's wrong with the name?
gnusty_gnurc 6y ago
Yea I was searching to see if anyone else would mention this, especially seeing the uproar about GIMP, etc. I don’t care about the naming dispute stuff, but this is comically close to pee-hole.

Technically 6y ago

Does this allow for semantic, non-text diffing? This would allow for code formats without syntax errors (i.e. storing the valid AST in binary as separate, likely structured in binary, from the editor representation). Diffs would then be truly semantic, representing semantic refactorings (e.g. "extract method to function", "rename symbol") at the patch level. you could easily then query "when did this variable show up" even post-refactor where the variable moves modules. Sure this has its limits but it'd push the tooling to levels virtually impossible to automate with text-based code now. A man can dream!

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 with other changes.
- yencabulator 6y ago
  By that logic, so does Git (disregarding fundamental Git vs Pijul differences).
gnufx 6y ago
Darcs has "replace" for that, the only other patch type that's been implemented for it as far as I know. I think Toolpack provided that for Fortran in the 1980s, but I don't remember for sure whether its version control was AST-based latterly (and, of course, it wasn't networked, let alone distributed).

jgalt212 6y ago

This write up is very kind to Git (vis a vis one of it pros): > Intuitive method and interface for version tracking

pmeunier 6y ago
https://www.reddit.com/r/programming/comments/k39td1/pijul_the_mathematically_sound_version_control/ge1w28y/?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/programming/comments/k39td1/pijul_t...

gnufx 6y ago

I asked before, but didn't get an answer. Darcs is criticized for lack of soundness and potential exponential merge complexity -- which I'm not sure I've actually run into -- but that's Darcs2. I haven't actually followed along, but I thought the development Darcs3 is an answer. This may not be the place to ask, but can anyone compare the new Pijul and Darcs3?

nieve 6y ago

With this latest release does Pijul now have an extensive test harness to prevent the corruption & data loss in repositories that people have been experiencing for years? I know pre-1.0 versions had low visibility warnings that you shouldn't actually use Pijul for any code you cared about, but I'd assume that is no longer true for a 1.0 version. I've been very interested as an on-again off-again Darcs user, but when people were reporting that it destroyed their data it was a kind of scary step to take.

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 line tool itself ;-) More seriously, one major issue with the 0.x versions was that bad performance meant we couldn't really test it massively. But now we can, and actually one of my first tests was to try and import the history of Nixpkgs, and run massive checks for data loss after every operation. It works now.
- speedkills 6y ago
  As scalability was one of the design goals. are there any comparisons of performance with huge repos?