91–100 of 212 posts
Earlier quoted context omitted.
More like merges but actually neither… it can reorder patches, even conflicting ones, it’s a completely foreign concept in git.
sounds like rebase with force push remote. (well, every push is a force push in git. so just rebase+push. ...except on github if you have "protected branches")
> However, channels are different from Git branches, and do not serve the same purpose. In Pijul, independent changes commute, which means that in many cases where branches are used in Git, there is no need to create a channel in Pijul. I've never understood this. AFAIK, the only use case I've ever seen for git branches is "I have some code, but don't want it going live yet". Maybe it's a WIP demo, maybe you want som…
A common case for git branches is long-life versions. For example, one git branch can be for version 1.0 and one git branch can be for version 2.0. This can be good for major upgrades, as well as for site-specific installations, as well as for regulated industries that need to audit specific versions.
Earlier quoted context omitted.
Pijul eliminates the rift between rebases and merges. That in itself is an enormous gain over the confused git workflow or lack thereof.
And what is it? couldn't find on the "doc"... is it all rebases or all merges?
I seem to recall very positive comments regarding pijul's underlying architecture/theory. However, as I don't have the headspace to delve into it, I would love a blurb at the beginner level that highlights the benefits of using pijul compared to other VCS, and a very brief and simple comparison between pijul and git (focusing on the differences).
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. Explai…
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…
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 number it produces, great. If more than what Git produces, that's a barrier to adoption, as merge conflicts are one of the biggest pains when using Git.
For me though what appears one of its biggest strengths (commutative workflow) is also its biggest drawbacks. There are so many teams that are trained in git workflow and are used to it, that getting them to switch to a completely different style of workflow in sufficient numbers will take years.
Git compatibility is a key missing feature. Git had this with Subversion, and I think it's a big reason why Git won over many of the Subversion crowd.
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…
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.
Tho I guess it cheats existing in an image-based world (I have never used it, it's just something stuck in my memory from many years ago).
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…
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.
Earlier quoted context omitted.
> 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. Hmm...that seems like a feature to me, not a bug. To me nothing of substance should happen in the repository, it should all happen in the local working directory. ¯\_(ツ)_/¯
> To me nothing of substance should happen in the repository, The idea is that with pijul nothing of substance would happen on the server in this example, it is the same process that would happen if you were doing it all locally.
So it's a low-impact optimization of the fast path?
But actually, how does pijul know there are no conflicts? Textually?
https://pijul.org/manual/conflicts.html
Hmmm...yeah looks like it's purely textual. Er, no. There can be semantic conflicts that I need to resolve that do not conflict textually. The test suite needs to be green locally on my machine, and then we replace the Top of Tree wholesale with the code that passed the tests locally on my machine.
So to me this feature of pijul is clearly an anti-feature, a bug, and the git behavior is correct.
I'm watching Pijul from afar for years now. I'd love to see it get 1% of the investment Github gets...