61–70 of 212 posts
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…
Earlier quoted context omitted.
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…
> 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…
Funny timing of this post. This past weekend, I dedicated myself to creating a comprehensive set of tools for integrating Pijul seamlessly into Emacs. This includes collaboration features through org-mode, which I believe will be refreshing. I'm eager to share it with the community shortly. For fellow Emacs & Pijul enthusiasts, keep an eye out!
> Do files merged by Pijul always have the correct semantic? > No. Semantics depends on the particular language you’re using, and Pijul doesn’t know about them.
That makes it sounds like Pijul might sometimes merge two functionally correct versions of a file into an unfunctional, incorrect one? Is this referring to a problem git and other merge tools have as well, or is it unique to Pijul and a result of being so good at merging without conflicts that it sometimes lets through semantic conflicts?
Hey what does this item in the FAQ mean? > Do files merged by Pijul always have the correct semantic? > No. Semantics depends on the particular language you’re using, and Pijul doesn’t know about them. That makes it sounds like Pijul might sometimes merge two functionally correct versions of a file into an unfunctional, incorrect one? Is this referring to a problem git and other merge tools have as well, or is it uni…
It doesn't happen very often, but it is still worth running integration tests after a merge even if both branches were passing tests on their own.
Hey what does this item in the FAQ mean? > Do files merged by Pijul always have the correct semantic? > No. Semantics depends on the particular language you’re using, and Pijul doesn’t know about them. That makes it sounds like Pijul might sometimes merge two functionally correct versions of a file into an unfunctional, incorrect one? Is this referring to a problem git and other merge tools have as well, or is it uni…
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.
Earlier quoted context omitted.
git can already do this as long as there isn't a conflict. Maybe pijul has better three way conflict resolution, but those can be risky, and avoiding those rare situations wouldn't offset the vast amount of tooling that got has.
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…