Hacker News Reader

Comment by erlend_sh | Hacker News Reader

For a strong contender to "next-gen DVCS", I recommend checking out 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.

View on HN

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.

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.

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.

> 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).

> 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.

Heck there are places that use ClearCase still.

Companies that are at rest tend to stay at rest.

As far as code is concerned I fully agree. But DVCS tools have a much broader utility for content sharing (documentation, teacher's resources, screenplays etc.) that we've only just begun to explore.

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

cf darcs

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.

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.

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).

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.

You don't alias git to just g?

And pijul naturally goes to "pj"...

It gives new meaning to working in your PJs.

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/f7eb66a52a67b9c43762...

That sounds identical to darcs' pitch - 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-pr...

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...

Pijul is definitely inspired by darcs and from what I've seen most of its team is very familiar with darcs.

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

Reply on news.ycombinator.com