Comment by jillesvangurp | Hacker News Reader

Comment by jillesvangurp | Hacker News Reader

Parent Full thread

As somebody not using this, it looks like the main obstacles to this getting popular (assuming it works as advertised and it's easy to use, I wouldn't know):

- Work on the pitch and clearly state the problem this is solving instead of mainly talking about the competition. What makes this unique? Why should people care?

- Make it easy to start using this for teams. My guess is that this is where a lot of developers fail to convince others in their teams. Back in the day when I started using Git, interfacing with existing svn repositories was a key selling point for me. Likewise, I helped migrated a big cvs repository to subversion when that was new. Key selling point there: we don't loose our version history. This is a complex topic of course but I bet there are actually a lot of solutions here.

- Show that there's an ecosystem. Who is using this? What tools are there? Are there any project hosting things that I can use? Answer these questions. This is about taking away any concerns people might have about using this that are perhaps half convinced already.

This is a chicken and egg problem and I don't see a way out of it.

Even if Pijul is better (not voicing an opinion here), it's not drastically better enough to replace Git in widespread use in the near term. The difference in day to day use is not huge.

And it is better in handling certain merge situations that are painful in git, but most programmers don't run into these often enough to care.

> What makes this unique?

It's patch based rather than snapshot based.

> Why should people care?

It avoids certain merge scenario problems that git makes painful.

> when I started using Git, interfacing with existing svn repositories was a key selling point for me

Pijul can import and export to Git (and probably others) with less problems than git vs. svn (because SVN is not distributed and had a weird branching model).

> Show that there's an ecosystem

Here's the chicken and egg problem again.

There's a "free" hosting service advertised on the front page. Or you can use it with your git hosting (but lose some of the advantages).

But GitHub and GitLab have their own CI systems and other infrastructure which isn't going to be easy or cheap to replace.

So yeah, I think that Pijul is a great piece of technology that solves a real problem we have with Git, but it's unlikely to overcome the inertia that Git{Lab,Hub,} have.

I would suggest adapting the website to communicate those points a bit more clearly. The communication on that website isn't great. It's a common problem with things techies build for other techies.

The key friction getting users to switch from something they already use is articulating why that is worth doing and investing lots of time in and/or making the point that it's really easy to switch is the main job of that website. Without that, most people simply won't.

The point with an ecosystem is that there won't ever be one worth talking about unless people work hard to build one. "Build it and they will come" rarely works. This website isn't good enough to make that happen.

> Here's the chicken and egg problem again.

Back when git had their chicken-and-egg problem, there were hundreds if not thousands of FOSS project members independently starting threads on mailing lists about how and/or when to move to git. Many of them were already using the git web server thingy and manually syncing with svn or whatever.

Some contrarians aside, the general consensus at that time was, "Yes, that clearly does solve some real pains we currently experience on a regular basis (branching, local branching, renaming files, etc.), but how do we practically move to it?"

Practically moving to it required the infrastructure. So you had a classic chicken and egg problem, until whatever broke it (sourceforge adding git compatibility? github?).

With Pijul you have a small number of adherents who have trouble explaining the pains that Pijul addresses, much less how common those pains are in the average git project. So you haven't yet arrived at the question of how to switch to Pijul-- you're still at the question of why anyone should.

Put another way-- you don't have any potential chickens longing to be incubated in an integrated Pijul hub/CI environment. If one poofed into existence, it might hatch chickens. Then again, it might go relatively unused. So I don't have a chicken and egg problem here.

When git came out it was (arguably) miles better than SVN and others. It was a big leap from centralized to decentralized version control.

Git to Pijul is a much smaller change, it is much more difficult to justify.

And then there is the fact that popular CI solutions are tied to GitHub and GitLab which increases the friction significantly.

> Git to Pijul is a much smaller change, it is much more difficult to justify.

Having used both extensively, I don't think this is true at all. I don't see as much difference between SVN and Git, as I see between these two and Darcs/Pijul (even though Darcs has scaling issues).

Reply on news.ycombinator.com