5 ms·

For a strong contender to "next-gen DVCS", I recommend checking out https://pijul.org/ https://pijul.org/. Written in Rust and based on a sound theory of patch

For a strong contender to "next-gen DVCS", I recommend checking out https://pijul.org/ https://pijul.org/. Written in Rust and based on a sound theory of patches. If GitLab actually merges Mercurial, I sincerely hope Pijul is next.

mattbee 8y ago
That sounds identical to darcs' pitch - http://darcs.net/DifferencesFromGit http://darcs.net/DifferencesFromGit darcs was an absolute pleasure to use, right up until they got stuck on the "merge of doom" bug http://darcs.net/FAQ/Performance#is-the-exponential-merge-problem-fixed-yet http://darcs.net/FAQ/Performance#is-the-exponential-merge-pr...
- autopoiesis 8y ago
  I think pijul's algorithms avoid the "exponential merge problem", though I don't know the details: https://pijul.org/manual/why_pijul.html#better-conflicts-for-everyone https://pijul.org/manual/why_pijul.html#better-conflicts-for...
- WorldMaker 8y ago
  Pijul is definitely inspired by darcs and from what I've seen most of its team is very familiar with darcs.
sleavey 8y ago
On a shallow note, I hope the command is changed or aliased if this becomes mainstream - writing "pijul" at the start of every command is awkward on English keyboards given that all the letters are near to each other on one side. Writing "git" or "svn" on the other hand, the letters are spread across the keyboard and shared between hands.
- Already__Taken 8y ago
  You don't alias git to just g?
  - autopoiesis 8y ago
    And pijul naturally goes to "pj"...
    - unstuckdev 8y ago
      It gives new meaning to working in your PJs.
  - majewsky 8y ago
    I don't have that alias, but I have a shellrc snippet for upcasting all Git aliases into shell aliases. For example: $ $ git config -l | grep checkout alias.co=checkout $ which co co: aliased to git checkout Source: https://github.com/majewsky/devenv/blob/f7eb66a52a67b9c437626ef6b86ded10446d30b0/toplevel/zshrc#L51-L53 https://github.com/majewsky/devenv/blob/f7eb66a52a67b9c43762...
simias 8y ago
Pijul looks very interesting but unfortunately as it stands (and without a huge open source project à la Linux to back it) I can't really imagine it taking over git as it stands. It might be better than git but is it enough an improvement to justify the cost of switching? I'm not sure. Now if pijul takes inspiration from Fossil and implements things like issue tracking as part of the DCVS then that would be an other story as far as I'm concerned. That would be a pretty radical upgrade from git.
- ATsch 8y ago
  My hope is that what will happen is that git sees what Pijul does and integrates some of it's innovations and copies them. I don't know how feasible this is though, technically.
  - kasabali 8y ago
    That's not gonna happen. Pijul's innovations originated in SCMs much older than git, and Torvalds evaluated all those SCMs before deciding to create git, so he was well aware of those ideas. If it didn't happened in the beginning I doubt it'll happen in the future.
- knocte 8y ago
  > Pijul looks very interesting but unfortunately as it stands (and without a huge open source project à la Linux to back it) I can't really imagine it taking over git as it stands. It might be better than git but is it enough an improvement to justify the cost of switching? I'm not sure. Nailed it. And you could argue in an analogous way about all the cryptocurrencies that try to be "better" than bitcoin/ethereum (offtopic I know).
- epicide 8y ago
  > is it enough an improvement to justify the cost of switching? This is the main question everybody should be asking about potential contenders [0]. For most places, switching would be a huge undertaking. Even if there's an import tool that works flawlessly (big assumption), you now have to potentially re-think all of your secondary tooling [1]. Not just 3rd party tools, either. You have to think about potentially tweaking build pipelines, etc. Not to mention (re)training people which is very likely orders of magnitude more costly [2]. For any potential tool to overtake git, it will have to provide some pretty extreme benefits. Git originally provided some pretty extreme benefits over SVN and yet there are plenty of places that still can't justify the cost of even making that switch. [0]: I'm only talking about contenders for large projects and/or business' ecosystems. Use whatever you want on your side projects. [1]: GitLab adding support for alternatives is a good way to start mitigating this. [2]: In more ways than just purely financial.
rejschaap 8y ago
I would call it a "theoretically sound current-gen DVCS". Unfortunately, theoretically sound is no guarantee for success, quite the opposite.
- fnord123 8y ago
  cf darcs
  - simias 8y ago
    I recall that one of the main problems with darcs is that it was almost comically slow even on moderately sized codebases. I suppose it might have improved later on but by then Git and Hg were too far ahead.
    - stevekemp 8y ago
      Darcs was plagued with speed issues. With just the "right" set of patches you could watch it spin for infinite amounts of time. That said darcs was a pleasure to use, when it worked, and I have fond memories of it if I ignore the speed/corruption issues.
    - WorldMaker 8y ago
      Part of the problem of darcs wasn't so much that it was slow (it was fast enough in most day-to-day operations), it was that it was hard to predict when it might be slow in a given operation. Slow performance across the board is something that you can solve at scale by throwing more hardware at it or producing warnings/progress statements for it (there are a lot of cases where you don't care how long something takes if it just gives you a well updated progress bar for it). Slow performance under circumstances you and the app can't predict is a lot harder (an unwelcome relative of our good old friend, the Halting Problem).
krupan 8y ago
Warning that the UI is still missing a lot, even though the theory and basis should give it a lot of power eventually.

mattbee 8y ago

That sounds identical to darcs' pitch - http://darcs.net/DifferencesFromGit http://darcs.net/DifferencesFromGit darcs was an absolute pleasure to use, right up until they got stuck on the "merge of doom" bug http://darcs.net/FAQ/Performance#is-the-exponential-merge-problem-fixed-yet http://darcs.net/FAQ/Performance#is-the-exponential-merge-pr...

autopoiesis 8y ago
I think pijul's algorithms avoid the "exponential merge problem", though I don't know the details: https://pijul.org/manual/why_pijul.html#better-conflicts-for-everyone https://pijul.org/manual/why_pijul.html#better-conflicts-for...
WorldMaker 8y ago
Pijul is definitely inspired by darcs and from what I've seen most of its team is very familiar with darcs.

sleavey 8y ago

On a shallow note, I hope the command is changed or aliased if this becomes mainstream - writing "pijul" at the start of every command is awkward on English keyboards given that all the letters are near to each other on one side. Writing "git" or "svn" on the other hand, the letters are spread across the keyboard and shared between hands.

Already__Taken 8y ago
You don't alias git to just g?
- autopoiesis 8y ago
  And pijul naturally goes to "pj"...
  - unstuckdev 8y ago
    It gives new meaning to working in your PJs.
- majewsky 8y ago
  I don't have that alias, but I have a shellrc snippet for upcasting all Git aliases into shell aliases. For example: $ $ git config -l | grep checkout alias.co=checkout $ which co co: aliased to git checkout Source: https://github.com/majewsky/devenv/blob/f7eb66a52a67b9c437626ef6b86ded10446d30b0/toplevel/zshrc#L51-L53 https://github.com/majewsky/devenv/blob/f7eb66a52a67b9c43762...

simias 8y ago

Pijul looks very interesting but unfortunately as it stands (and without a huge open source project à la Linux to back it) I can't really imagine it taking over git as it stands. It might be better than git but is it enough an improvement to justify the cost of switching? I'm not sure. Now if pijul takes inspiration from Fossil and implements things like issue tracking as part of the DCVS then that would be an other story as far as I'm concerned. That would be a pretty radical upgrade from git.

ATsch 8y ago
My hope is that what will happen is that git sees what Pijul does and integrates some of it's innovations and copies them. I don't know how feasible this is though, technically.
- kasabali 8y ago
  That's not gonna happen. Pijul's innovations originated in SCMs much older than git, and Torvalds evaluated all those SCMs before deciding to create git, so he was well aware of those ideas. If it didn't happened in the beginning I doubt it'll happen in the future.
knocte 8y ago
> Pijul looks very interesting but unfortunately as it stands (and without a huge open source project à la Linux to back it) I can't really imagine it taking over git as it stands. It might be better than git but is it enough an improvement to justify the cost of switching? I'm not sure. Nailed it. And you could argue in an analogous way about all the cryptocurrencies that try to be "better" than bitcoin/ethereum (offtopic I know).
epicide 8y ago
> is it enough an improvement to justify the cost of switching? This is the main question everybody should be asking about potential contenders [0]. For most places, switching would be a huge undertaking. Even if there's an import tool that works flawlessly (big assumption), you now have to potentially re-think all of your secondary tooling [1]. Not just 3rd party tools, either. You have to think about potentially tweaking build pipelines, etc. Not to mention (re)training people which is very likely orders of magnitude more costly [2]. For any potential tool to overtake git, it will have to provide some pretty extreme benefits. Git originally provided some pretty extreme benefits over SVN and yet there are plenty of places that still can't justify the cost of even making that switch. [0]: I'm only talking about contenders for large projects and/or business' ecosystems. Use whatever you want on your side projects. [1]: GitLab adding support for alternatives is a good way to start mitigating this. [2]: In more ways than just purely financial.

rejschaap 8y ago

I would call it a "theoretically sound current-gen DVCS". Unfortunately, theoretically sound is no guarantee for success, quite the opposite.

fnord123 8y ago
cf darcs
- simias 8y ago
  I recall that one of the main problems with darcs is that it was almost comically slow even on moderately sized codebases. I suppose it might have improved later on but by then Git and Hg were too far ahead.
  - stevekemp 8y ago
    Darcs was plagued with speed issues. With just the "right" set of patches you could watch it spin for infinite amounts of time. That said darcs was a pleasure to use, when it worked, and I have fond memories of it if I ignore the speed/corruption issues.
  - WorldMaker 8y ago
    Part of the problem of darcs wasn't so much that it was slow (it was fast enough in most day-to-day operations), it was that it was hard to predict when it might be slow in a given operation. Slow performance across the board is something that you can solve at scale by throwing more hardware at it or producing warnings/progress statements for it (there are a lot of cases where you don't care how long something takes if it just gives you a well updated progress bar for it). Slow performance under circumstances you and the app can't predict is a lot harder (an unwelcome relative of our good old friend, the Halting Problem).

krupan 8y ago

Warning that the UI is still missing a lot, even though the theory and basis should give it a lot of power eventually.