Pijul is a free and open source (GPL2) distributed version control system

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.

In day to day use, there's very little difference in the practical use of git vs. pijul. You edit files, commit then push. Of course the user interface is different and some of the terminology is different but it's still a distributed version control system.

As for the differences, the advantages are listed right there on the front page: commutation, merge correctness, first-class conflicts and partial clones.

Explaining these in more detail in a short example ("a blurb") is not really easy because you'd have to first set up an example three way merge (for example) and then study the behavior of git vs. pijul in detail. I recall seeing a video presentation from the Pijul authors which delved deep into this if you're interested.

But I'll give it a go anyway...

tl;dr: pijul can handle certain merge situations automatically where git requires you to manually resolve them

I have the same question every time Pijul comes up on HN, and I have yet to get an answer:

Can someone give me a real world example (person a makes X change, person b makes y change etc. etc.) that would work better in Pijul than Git?

I am a complete believer on a sound underlying model producing better results for users at a high level, but I'm not clear on how it maps through for Pijul. I think that's what they're missing in the sell - the ability to explain to devs "it will make your life easier in the following specific ways".

For example when getting my employer moved from SVN to Git I could talk to people about how much easier it was to create and then merge a temporary branch for a feature in Git. Git understand the topology of the history, knew the merge base and had better merge algos so the only pain you had was when there was an actual conflict - two people editing the same file location. It also could track renames, which were incredibly painful to merge in SVN.

I have been following Pijul loosely for a while, and I would strongly agree that it could do with some information on some of the possible practical advantages of the approach. I do have some Pijul repositories around, but have not used it with the necessary further to explain any of the advantages, however, one possible advantage to note is that the equivalent of cherry-picking as used in GIT et. al, which always generates a new commit hash per cherry-pick for the same content should not happen in the Pigul world as I understand it. i.e. A specific commit when "cherry-picked" should have identical hashes, which has several implications.

- Having not actually tested this in my own repos, take my insight with the appropriate grain of salt.

> Can someone give me a real world example (person a makes X change, person b makes y change etc. etc.) that would work better in Pijul than Git?

Simplified example:

Persons A and B check out master branch.

Person A adds a.txt, commits and pushes.

Person B adds b.txt, commits and tries to push and...

1) git will not accept the push because it's not on top of current master branch, person B needs to fetch and merge/rebase before pushing again.

2) pijul will accept the change (after a pull, but no rebase) because patches A and B are independent of each other and does not matter which order they are in the history (keyword: commutation).

The value of Pijul will only start to show when you get into big three way merge scenarios. Which git users avoid like the plague because they are so nasty to deal with. Demonstrating this would need a much larger example.

edit: clarification a pull is still needed in case 2, but no rebase or merge because there isn't one for commutative patches