Live data from Hacker News

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

pijul.org

211–212 of 212 posts

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

#211
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…

Merges are bad only when all parties involved edited the same code. There's no programmatic way to solve this problem. It's an administrative problem: someone has to decide whose code is the right one to use. If changes coming from both sources are independent, then rebase in Git is trivial as well, and there's nothing to be afraid of.

> It's an administrative problem: someone has to decide whose code is the right one to use.

Or maybe an architectural one.

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

#212

Earlier quoted context omitted.

Git would make you merge or rebase, but yes there wouldn't be a conflict. They're saying Pijul would let you directly push without having to deal with the diverging histories.

Which tbh is a bad thing. Just because change a doesn't textually touch change b doesn't mean they don't interact. Unless your VCS is handling CI for integrating changes on push, you really need to pull down the upstream changes first and test them combined with your code before blindly pushing.

> Which tbh is a bad thing. Just because change a doesn't textually touch change b doesn't mean they don't interact.

A good example for this is code which grabs several locks and different functions have to do that in the same order, or a deadlock will result. A lot of interaction, even if changes might happen in completely different lines.

And I think that's generally true for complex software. Of course it is great if the compiler can prove that there are no data race conditions, but there will always be abstract invariants which have to be met by the changed code. In very complex code, it is essential to be able to do bisecting, and I think that works only if you have a defined linear order of changes in your artefact. Looking at the graphs of changes can only help to understand why some breakage happened, it cannot prevent it.

Post reply on HN