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

131–140 of 212 posts

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

#131

Post by lillecarl »

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 say that, but this applies to all cherry picking you can do between branches as well. As long as they don't conflict you're golden, and if there's a conflict you can commit a resolution that'll commute with your branch until you merge back into main.

It would enable so many nice and less strict workflows to actually work if it ever got momentum, I've still got hope.

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

#132

Post by grepknfss »

vlowther wrote: post #94
exDM69 wrote: post #14

Earlier quoted context omitted.

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…

More than that. If you have ever had to fix a bug in code common to multiple maintained releases of a project, being able to apply the same patch to them all as its own thing instead of having multiple cherry-picked commits with identical content would be nice.

I think giving a patch its own identity is a pretty neat concept and clearly different than the git approach, so thanks for this example!

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

#133

Post by WolfeReader »

WolfeReader wrote: post #129

Does Pijul handle branches better than Darcs? I _love_ using Darcs but I had to stop because there was no good way for my teammates to see my new branches (really separate repos) unless I told them myself.

Gotta say, I don't see anything about it in their site's "Documentation" link. Unless I hear different, I don't think I'm interested.

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

#134

Post by crabbone »

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 something, or to move things around one time, and then remove the other remote. Other times it was my hobby projects I shared with someone in some weird way.

Most developers who aren't in infra will never see a second remote in their repositories even once in their career. It seems like developing this functionality adds a significant overhead both in terms of development effort and learning effort on the part of the user. So... why?

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

#135

Post by crabbone »

exDM69 wrote: post #20
rkangel wrote: post #16

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…

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.

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

#136

Post by zemo »

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…

> Even I have to use git because who uses anything else?

It's pretty widely not used in the games industry because its support for media files is poor, it's pretty difficult to train artists to use it, the integration with game engines is pretty poor, git LFS is a layer of complication on a system that already has UX that's difficult for artists, git LFS hosting is an additional can of worms, there's essentially no file/directory-level permissions for managing contract work (and doing so with submodules+LFS is complicated).

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

#137

Post by danShumway »

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 simplicity. It's relatively easy for me to reason about what Git is doing under the hood. I like that I'm seeing that Pijul's patch operations are associative, I like at first glance what I'm seeing it say about merges, but it's not making it clear to me what the downsides are.

Is the idea that arbitrary checkouts take longer, but that's generally fine since people don't do them very often? Or am I over-estimating how much complexity/performance costs that building a vcs like this would incur?

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

#138

Post by adastra22 »

Zambyte wrote: post #50
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…

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

So long as you require git compatibility, you're kinda stuck with git's view of what history looks like. Which is rather the point.

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

#139

Post by zokier »

I feel I'm missing something; for a version control system, you'd think managing different versions would be kinda central but in pijul that seems more like an afterthought. If I'm reading correctly you could use 'channels' same way as you use git tags, but that doesn't seem to be happening in practice.

For example I look at 'sanakirja' project. The current version is 1.4.1 and the previous version was 1.4.0, and the version before that was 1.3.3:

https://crates.io/crates/sanakirja/versions

but if I look at the repository, there is no way to see any of that?

https://nest.pijul.com/pijul/sanakirja

There is "Tags" tab which is empty, and channel selection drop-down that has only "main" channel. So if I want to browse code at version 1.3.3, or see the difference between 1.3.3 and 1.4.0, or even just see what versions there are, how would I do that? To me those seem like very elementary questions, and yet reading through the manual I can find no hints toward this direction.

There is a FAQ entry that seems relevant:

> Is it possible to refer to a specific version?

> Excellent question. Since Pijul operates on patches rather than snapshots, versions are essentially unordered sets of patches. How do we communicate a specific version number to one another? We solve this by abusing elliptic curve cryptography primitives.

But its not clear at all how those "version identifiers" can be used or indeed if they are even implemented at all yet? At least based on the manual, no commands seem to take "version identifier" as argument, nor can I see them anywhere in Nest web UI.

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

#140

Post by adastra22 »

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…

There's no reason you can't cache tree snapshots in a pijul/darcs setting. That's just an implementation detail. The difference is more in how a rebase or merge operation works internally, and how essential the particular history is to the current workplace state.

Pijul does a better job of recognizing that "A -> B -> C" is the same as "B' -> A' -> C".

Post reply on HN