Live data from Hacker News

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

pijul.org

101–110 of 212 posts

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

#101
post #20

Earlier quoted context omitted.

> 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/re…

I believe that even git would work in this scenario because a.txt and b.txt are separate and independent thus a rebase in git is not required. The point at which this becomes an issue is when both person A and B try to make changes to the same file and specifically the same blob of text within that file. I could be wrong but this should be simple enough to prove out because I've run into this situation before where I…

> thus a rebase in git is not required.

A rebase is never required in Git. (people/maintainers may disagre) but a merge will always do.

Having said that. In your scenario provided, a pull + merge/rebase will be required. It will then resolve automatically, and without conflicts. But a human has to be involved to provide a strict sequence/dag of the those commits.

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

#102
post #66

As a left-handed person, that name is a nightmare to type.

That's what aliases are for. Regardless, I'm surprised that you even notice which hand you're typing with. For example, the word 'regardless' is mostly on my left hand and I'm right handed. But I wouldn't have noticed it if I didn't go looking for such words.

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

#103
post #37

I used darcs before git and it was very nice - the first distributed RCS I'd ever used. I believe pijul is a follow-on to that so it should be great. Later on I used Mercurial and it was very easy with a great GUI and it felt safe. git is like shaving with a straight shaving razor - alarming until you've developed your set of frequently used commands and ways to stay out of trouble. Even I have to use git because who…

but you know git and github are not the same thing right?

For the vast majority of OSS projects, you're much better off using Git and GitHub in terms of drawing attention and attracting contributors.

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

#104

I like how Pijul has a math-centric approach under the hood. The name needs to be changed if they want to get traction.

Just to provide a counterpoint: The name is great! Very memorable and original. Much better than your regular plooper, vndl or dabix.

Pijul also turns up easily on web searches, despite there being a bird with that name.

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

#105
post #98
post #68

Earlier quoted context omitted.

All version control tools have the same problem since AFAIK none of them care about the semantics of the program being version-controlled (except Unison). For example, in file foo.js you export the function foo. Now, if you delete the function foo, while your colleague import it into bar.js, the resultant changes are consistent, but the program is now functionally broken.

Plsstic's diff tool is also centered around syntactic units of the programming language rather than stupidly scanning for line breaks, if it recognizes the language.

That still wouldn't mean that the merge is semantically correct.

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

#106
post #69
post #30

Earlier quoted context omitted.

You kinda missed the point. You have two repos with different history: master -> patch a -> patch b master -> patch b -> patch a But the contents of the files are equal after applying both patches (in either order). Git will consider these to be two different, Pijul thinks they're the same. This is a simplified example. It only gets interesting when there are a lot of patches, some of which are commutative and some a…

What benefit is there to the VCS knowing that these histories are equal? That's valuable in verification or efficient binary patching, but I don't see how it matters in version control. When would I want to compare two repositories that were patched in different orders?

Imagine you are working on a patch heavy project. Like the Linux kernel. Where there are a lot of patchsets going around that are not in the mainline.

You and I, who are both working off of main, and who have both separate merged in a few patchsets that are relevant to our shared module of interest. We can merge and compare our branches, and the differences in terms of nursing patches without having to be rigorous about reconciling or histories.

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

#107
I'm watching this (and Jujitsu, Sapling, etc.) with interest, but I wish there was more focus on Git's real weak areas. Yes it sometimes makes merge conflicts more difficult than it could, but you can generally deal with that. The bigger problems are:

* Poor support for large/binary files. LFS is bare-minimum proof of concept.

* Poor support for large projects. Big monorepo support is definitely getting better thanks to Microsoft. Submodules are a disaster though.

How does Pijul support large files and large projects?

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

#108

Missing FAQ: Is the "j" in Pijul hard or soft?

Don't know what hard or soft supposed to mean in a hypothetically ambiguous context, but the `j` here is obviously a Voiceless velar fricative (`x` in IPA). Think loch (Scott.), Χάρων (Gr.), joven (Sp.), хлопець (Ukr.) https://en.wikipedia.org/wiki/Voiceless_velar_fricative

~~"obviously"? Why?~~ aha! see edit 2

That pronunciation had temporarily escaped me. I was trying to decide between a voiced postalveolar affricate d͡ʒ (hard) or voiced palatal approximant j (soft).

https://en.wikipedia.org/wiki/Voiced_postalveolar_affricate

https://en.wikipedia.org/wiki/Voiced_palatal_approximant

Edit: "hard" and "soft" seemed like the most logical way to describe what I thought was a dichotomy, particularly as it's also often used to distinguish between the voicings of "c" and "g".

Edit 2: Just read the whole FAQ (rather than searching for "pronunciation" or related terms), and noticed the "Where does the name come from?" entry, which mentions the Mexican origin, which is why "x" is "obviously" correct.

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

#109
post #2

I'm watching Pijul from afar for years now. I'd love to see it get 1% of the investment Github gets...

Github can use/offer Pijul. Sure they named themselves after technology, but nothing prevents them to offer other control systems.

Nothing except their own arrogance. See svnhub.com. It was registered by github to block potential competition long before SVN support on github became available.

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

#110

I have used professionally Darcs, Mercurial, Subversion, and Git. I love distributed version control systems, and I love Git. However, Pijul looks interesting, nice work! Pijul has a number of stated strengths over Git, and looks like the version history is implemented as a CRDT from my first impression. Some of the statements make me wonder how many conflicts occur in real use. If they are equal to or less than the…

The basic premise of Pijul is that the way they model changes leads to better merges, fewer conflicts, and (crucially) no cases of bad merges. Git can complete merges and do it incorrectly. https://pijul.org/manual/theory.html

This means that in some cases, Pijul will correctly merge where any of the git merge strategies would create a conflict. It also means that in some other (rarer) cases, Pijul will generate a conflict where git would not: git would guess, in effect, and either get it right or get it wrong. I consider both of these things to resolve in Pijul's favor.

The Pijul model also means that conflicts preserve some crucial state which can be used to resolve the merge. A conflict is modeled as a specific data structure, not as special syntax intruded into the source file. One example of this is that conflicts can in some circumstance be resolved by applying more patches, because the conflict is metadata about the file, it isn't data in the file which screws with subsequent state changes.

Post reply on HN