5 ms·

> Git is pretty nice, but I'm sure there is something much better waiting to he invented. It is indeed being invented. It’s called Pijul: http://pijul.org/ htt

> Git is pretty nice, but I'm sure there is something much better waiting to he invented. It is indeed being invented. It’s called Pijul: http://pijul.org/ http://pijul.org/ This tool is based on strong mathematical theory of patches, instead of snapshot/commit-based. It seems simpler to reason with, but we’d have to unlearn a lot from Git. It’s not suitable for big projects yet, but it’s already used by Pijul itself and other Rust components. And it already have its own „Github” called the Nest (because pijul is a bird). Pretty promising imho.

afiori 7y ago
I really like the promise of pijul, but it is early to say if it is better. Conventions and tooling will be a decisive factor in the ease of use. That said I do share your optimism.
gbersac 7y ago
Exactly the kind of program which will benefit from being wrote in rust.
stevekemp 7y ago
I had a sudden flashback to using darcs, which was also based upon patches instead of commits. darcs was nice, up until you hit the exponential merge problem.
- afureta 7y ago
  I don't know about Pijul, but it claims to have solved the exponential merge problem. https://pijul.org/faq/ https://pijul.org/faq/
- pmeunier 7y ago
  I'm one of the authors. Pijul is indeed heavily inspired by Darcs, but we solved that problem completely. All our algorithms are in time at most log of the size of history, which is a double-exponential improvement over Darcs' worst case complexity.
dahart 7y ago
> This tool is based on strong mathematical theory of patches Is this a good thing? What practical problems does a strong mathematical theory of patches solve that git doesn’t? And what’s the difference between a commit and a patch? Aren’t git commits stored as patches? I’m a math lover, but my gut reaction to that idea is that it sounds off-putting. I don’t mean that as a judgement or insult; I’m admitting my own assumption and bias here, jumping to unwarranted conclusion, not saying anything is wrong with pijul. But when the elevator sales pitch is “strong math”, it immediately makes me assume it’s too technical for a normal programmer and focused on academic ideals rather than getting practical work done as easily as possible. The FAQ even says, “Pijul is trivial for whoever knows category theory.” Is that question really asked frequently? Words like that might convince me to never try it. ;)
- cesarb 7y ago
  > Aren’t git commits stored as patches? No, they aren't, git commits are stored as snapshots. Each git commit has one tree, which is a snapshot of the state after the commit; zero or more parent commits; a pair of authors with corresponding timestamps; a commit message; and nothing more. Any patch you see in git is an illusion, made by comparing the commit's tree with the parent commit's tree.
  - dahart 7y ago
    Thank you. Sheesh I feel like I should have known this about git. That would make diffing very far apart changes super fast. So what's the advantage to explicit storage in patches over snapshots? Are diffs between snapshots not able to capture the same information that explicit patches have?
    - erik_seaberg 7y ago
      The trouble with patches is that you can't get engineers to reliably declare whenever they copy or move code and where it came from. This is part of why svn merging was such a trainwreck, undeclared copies and moves (which look like delete+insert) almost always conflicted.

afiori 7y ago

I really like the promise of pijul, but it is early to say if it is better. Conventions and tooling will be a decisive factor in the ease of use. That said I do share your optimism.

gbersac 7y ago

Exactly the kind of program which will benefit from being wrote in rust.

stevekemp 7y ago

I had a sudden flashback to using darcs, which was also based upon patches instead of commits. darcs was nice, up until you hit the exponential merge problem.

afureta 7y ago
I don't know about Pijul, but it claims to have solved the exponential merge problem. https://pijul.org/faq/ https://pijul.org/faq/
pmeunier 7y ago
I'm one of the authors. Pijul is indeed heavily inspired by Darcs, but we solved that problem completely. All our algorithms are in time at most log of the size of history, which is a double-exponential improvement over Darcs' worst case complexity.

dahart 7y ago

> This tool is based on strong mathematical theory of patches Is this a good thing? What practical problems does a strong mathematical theory of patches solve that git doesn’t? And what’s the difference between a commit and a patch? Aren’t git commits stored as patches? I’m a math lover, but my gut reaction to that idea is that it sounds off-putting. I don’t mean that as a judgement or insult; I’m admitting my own assumption and bias here, jumping to unwarranted conclusion, not saying anything is wrong with pijul. But when the elevator sales pitch is “strong math”, it immediately makes me assume it’s too technical for a normal programmer and focused on academic ideals rather than getting practical work done as easily as possible. The FAQ even says, “Pijul is trivial for whoever knows category theory.” Is that question really asked frequently? Words like that might convince me to never try it. ;)

cesarb 7y ago
> Aren’t git commits stored as patches? No, they aren't, git commits are stored as snapshots. Each git commit has one tree, which is a snapshot of the state after the commit; zero or more parent commits; a pair of authors with corresponding timestamps; a commit message; and nothing more. Any patch you see in git is an illusion, made by comparing the commit's tree with the parent commit's tree.
- dahart 7y ago
  Thank you. Sheesh I feel like I should have known this about git. That would make diffing very far apart changes super fast. So what's the advantage to explicit storage in patches over snapshots? Are diffs between snapshots not able to capture the same information that explicit patches have?
  - erik_seaberg 7y ago
    The trouble with patches is that you can't get engineers to reliably declare whenever they copy or move code and where it came from. This is part of why svn merging was such a trainwreck, undeclared copies and moves (which look like delete+insert) almost always conflicted.