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

151–160 of 212 posts

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

#151

Post by ljm »

Zigurd wrote: post #119
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 is empirical evidence that git is diabolical: Git can be thought of as an experiment in how to make an API GUI-proof. There is no possible direct manipulation visual representation of git operations that doesn't dumb it down.

I content that magit, while not a GUI, pretty much transcends git’s CLI.

GUIs will only ever tackle a subset of git’s functionality since if you’re already a power user you’ll be comfortable with the command line.

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

#152

Post by zokier »

zokier wrote: post #139

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…

Oh, apparently there is `pijul tag` command that might do something relevant here?

https://nest.pijul.com/pijul/pijul:main/QL6K2ZM35B3NI.JIAAA

but the docs do not say anything about that, so it remains a mystery. also its still weird that their own projects do not use those tags, or is it just that the web UI isn't showing them properly?

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

#153

Post by danShumway »

adastra22 wrote: post #140
danShumway wrote: post #137

Earlier quoted context omitted.

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

On first download/checkout then I assume I'd download the tree snapshot and it wouldn't replay the patches at all? Local caching would help with repeated checkouts, but most of the time I use Git I'm moving around, so I'm not sure how often I would benefit from that. That also seems like it would lose some verifiability for checkout integrity (?), but maybe that's not a big deal, I'm not sure in practice how much that matters for Git.

Repo size also comes to mind on this if snapshots/caches are happening regularly/automatically, since that would mean Pijul is storing both the patches and the end states rather than computing the patches on the fly. But I guess snapshots wouldn't need to be automatic -- I'm not sure how often people actually check out arbitrary commits, maybe you could get away with only caching certain points?

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

#154

Post by rendaw »

zemo wrote: post #136
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 f…

Do you know of any FOSS alternatives that handle that stuff better (specifically binary asset handling and permissions)?

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

#155

Post by mdaniel »

1oooqooq wrote: post #73

Does it accept per-repo settings? (e.g. git config --local) Does it use proper SSH? (e.g. `git clone my_entry_on_ssh_config:/repo_path.git`)

I seemingly can't link to line numbers in their nest thing, but https://nest.pijul.com/pijul/pijul:main/SXEYMYF7P4RZM.ERRQA#... is ssh.rs in the pijul-remote directory, so presumably "yes"

also, an especial :fu: to whatever the hell is going on with SXEYMYF7P4RZM.ERRQA being a permalink to a file with a specific name, forcing me to write out in english what's going on there

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

#157

Post by zemo »

rendaw wrote: post #154
zemo wrote: post #136

Earlier quoted context omitted.

> 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 f…

Do you know of any FOSS alternatives that handle that stuff better (specifically binary asset handling and permissions)?

some indies use Subversion, but Perforce is the industry standard.

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

#158

Post by sunshowers »

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…

That is definitely a tradeoff. On the other hand, the history of all human progress is a history of path dependence. Constraints spur creativity and Jujutsu works extremely well.

(I've worked with the main author of Jujutsu before. Also, having worked on Mercurial for many years, I have my biases about how source control should work. Jujutsu's workflow is very similar to Mercurial's, with some rather stunning improvements on it.)

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

#159

Post by manithree »

zck wrote: post #74

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

I had the same question. Turns out, it's mostly a future possibility, and for most current use cases of branches in git, you would use a channel in pijul. At least that's how I understand these discussions in the pijul discourse.

https://discourse.pijul.org/t/phenomenological-pijul-or-piju...

https://discourse.pijul.org/t/working-without-channels/1047/...

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

#160

Post by davorak »

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…

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

Unlike git, pijul has first class conflicts, pijul unlike git does not reject in this example.

My knowledge is limited, but from my testing that means the conflict exists in the history, at least if your merge style allows for that(similar to how in git you can choose to always rebase or use merge commits).

The conflict is resolved with a new patch.

I did not spot much in the documentation with a quick search but on the man page there is a small blurb on first class conflicts

> First-class conflicts In Pijul, conflicts are not modelled as a "failure to merge", but rather as the standard case. Specifically, conflicts happen between two changes, and are solved by one change. The resolution change solves the conflict between the same two changes, no matter if other changes have been made concurrently. Once solved, conflicts never come back.

- from https://pijul.org/

Post reply on HN