Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

pijul.org

Post reply on HN
Print view View original

141–150 of 212 posts

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

#141

Post by skybrian »

t43562 wrote: 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…

There are many people who work on open source professionally, but as a hobbyist programmer I find it odd to worry about Copilot automating my “job.” This is like complaining that your dishwasher or robot vacuum cleaner automates your job because you don’t do the work by hand anymore.

If you’re getting paid then it makes some sense to worry about automation, but if you’re not, automation is good. You can do more. The community can do more. We can take on more ambitious projects.

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

#142

Post by hosh »

Communitivity wrote: post #96

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…

What I am excited about Pijul is being able to maintain a personal codebase that can accept changes from multiple upstreams. I’m not looking at commercial teams as much as homelabs or local-first environments.

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

#143

Post by keybored »

danShumway wrote: post #137
keybored wrote: post #81

So Pijul is patch-based. And not in the boring implementation-sense of storing changes as a series of patches. In the interesting sense that patches can be ordered in more arbitrary ways. On the other hand Git is snapshot-based. And Git was built for the Linux Kernel (specifically from the perspective of the lead maintainer). But my impression from the outside is that the Linux Kernel development is very “patch-based…

Genuine question, I have no opinion on this: My understanding is that a big part of the reason that Git is snapshot based is for reliability and for ease of checkout -- being snapshot based means Git doesn't need to replay commits every time you check things out. That likely comes with some downsides (cherry-picking does come to mind, yes), but also seems like some serious upsides, one of the biggest one being that s…

The original author sold it as a stupid content tracker. Which in part meant that the implementation was simple.

There ain’t a whole lot to the first commit of Git. Some hundred lines which consists of manually preparing a commit by sending the current snapshot to the “cache” (nowadays “index”) which compresses it and then building a commit by specifying the parents and a commit message (like git-commit-tree but I don’t know if that was around back then).

Beyond that I don’t know much.

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

#144

Post by adastra22 »

rkangel wrote: post #33
exDM69 wrote: 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…

Thank you for answering. For me "not needing to pull before pushing" is nice, but not game changing (but helpful to understand nonetheless). It's more the cases that you allude to that we instinctively avoid in git!

You've never maintained a long-lived git feature branch, it seems :)

I maintain a project that is a slight modification of a very active upstream repo. The changes I maintain are rather invasive. Almost every upstream commit introduces a merge conflict with my changes.

To keep myself sane I only merge/rebase when upstream releases a new version, but it still ends up sucking up a few weeks of my time every year. During those weeks, I look enviously at pijul where the conflicts would resolve down to a handful of corrections in context at the point of divergence, instead of gigantic merge conflicts obscured by thousands of piled on patches.

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

#145

Post by zemo »

crabbone wrote: post #134

I don't want this to be interpreted as a negative comment about Pijul: I didn't try it, and don't want to judge. My question is: what is the motivation for making distributed VCS? Over the entire lifespan of Git the number of times I had more than one remote... I can probably count on my fingers. And I've been in infra / ops for the better part of my career. And, all those times were exceptions . I'd do it to fix som…

> what is the motivation for making distributed VCS?

it depends on if you're asking about the motivations for distributed version control for linux kernel development in 2005 or the motivations for distributed version control today. git predates AWS and predates the state of the industry being that it's very easy and cost-effective for people to make central servers and web apps and things of that nature. My understanding is that "emailing a patch to a mailing list" was a more reasonable workflow then, since it piggy-backed off of people's email hosting providers (which, at that time, wasn't even "everyone using gmail", since back when git was created, gmail was invite-only; git predates gmail having open signups). Plus Subversion's branching model wasn't particularly great, so having different people work on things on different branches and giving them feedback and merging the branches when they were ready wasn't really a great experience.

The distributed nature of the version-control system facilitates branches, since a branch and a copy of the repo somewhere else are abstractly the same thing. Practically speaking, people don't push and pull code between their workstations and the network topologies are typically centralized in nature, but on a data level the distributed model is dual to the branching model, and the branching model is the thing that people actually care about. Although I _do_ think it's pretty neat that you can use a thumb drive or NAS as a remote instead of needing a server, it's probably not a core use-case for most people and most projects.

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

#146

Post by Zambyte »

adastra22 wrote: post #138
Zambyte wrote: post #50

Earlier quoted context omitted.

> Even I have to use git because who uses anything else? Git compatibility is a great way around this problem. I have been enjoying Jujutsu lately.

Not really. The real innovation of a lot of these alternative DVCS systems is that they free the state of the source from being dependent on the history that got you there. Such that applying patches A & B in that order is the same as applying B' & A' -- it results in the same tree. Git, on the other hand, hashes the actual list of changes to the state identifier, which is why rebasing results in a different git hash…

Jujutsu uses change IDs, which are an abstraction over commit IDs, that are stable over operations like rebasing.

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

#147

Post by skybrian »

magnio wrote: post #68
dahart wrote: post #65

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.

This is why we test our builds using continuous integration. Only updates that compile and pass the tests should be published.

How does Pijul handle continuous integration? If there’s nothing interesting going on with that then I don’t see how the UX can be any different for publishing new versions.

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

#148

Post by charcircuit »

gugagore wrote: post #34
h4ch1 wrote: post #15

Just like how Sapling is compatible with GitHub, I'd love to see Pijul being compatible with GitHub wrt creating at least a read-only mirror. I've seen this exists: https://github.com/purplesyringa/PijulGit , but hasn't been updated in 5 years.

Is sapling compatible? It gets rid of your .git directory.

It's network compatible in that you can clone, pull, push, etc with a github repo.

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

#149

Post by baq »

mpweiher wrote: post #99
davorak wrote: post #53

Earlier quoted context omitted.

> 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.

Hmm...so if something did need to happen, pijul would also reject and I would have to pull, do the local edits until everything is consistent and then push, just like git. 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 tha…

You’re describing CI, not git nor pijul, nor any other version control system.

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

#150

Post by dbacar »

skybrian wrote: post #141
t43562 wrote: 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…

There are many people who work on open source professionally, but as a hobbyist programmer I find it odd to worry about Copilot automating my “job.” This is like complaining that your dishwasher or robot vacuum cleaner automates your job because you don’t do the work by hand anymore. If you’re getting paid then it makes some sense to worry about automation, but if you’re not, automation is good. You can do more. The…

If you are a hobbyist programmer, it is not your "job" . So it is not automating your job for the moment but the professional programmers' job, isn't it?
Post reply on HN