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

171–180 of 212 posts

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

#171

Post by 1oooqooq »

mdaniel wrote: post #155
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

yeah the web think is pretty limited. no context lines on diffs at all, and I couldn't find a link to the full-file diff from the changeset. But i wouldn't worry too much about the nest usability yet.

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

#172

Post by pmeunier »

vim-guru wrote: post #41

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!

As probably the person in the entire world who has been wanting this for the longest, thank you! Please share on Pijul's Zulip, and ask for any help you may need.

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

#173

Post by 1oooqooq »

Aachen wrote: post #120
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`)

That honestly sounds like an implementation detail compared to figuring out what version control model even makes sense to begin with If you want local configs, worst case you can update $HOME inline and make it use different dotfiles. If ssh is a must, sshfs can be a way to achieve that

not being able to set ssh parameters (and key paths, etc) via .ssh/config was a nightmare on git a long time ago. impossible to not leak identities to random servers. impossible to have curated identities for the same remote. imposible to use adhoc jump hosts. etc.

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

#174

Post by pmeunier »

dooglius wrote: post #95
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…

The git behavior seems greatly preferable here. As mentioned in other threads, the notion of commutativity here is very weak and counterintuitive; it only seems to cover the applicability of an auto-merge heuristic, not any actual notion of correctness or semantics, so a human is needed to review the merge and re-test before anything can be known safe for pushing upstream. If anything, git is too lenient in allowing…

> the notion of commutativity here is very weak and counterintuitive; it only seems to cover the applicability of an auto-merge heuristic

This is completely false: in Pijul, any patches that could have been produced independently can be applied in any order without changing the result. There are 0 heuristics in Pijul, unlike in Git where even random line reshuffling can happen (there are examples in the "Why Pijul" section of the Pijul manual).

Obviously, deciding whether a merge has the correct semantic is Turing-complete, and Pijul doesn't try to do any of that.

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

#175

Post by IlliOnato »

jph wrote: post #82
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…

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.

I think the most common use for git branches is topic branches. Independent lines of development you are not ready to share with your team, or your team with the rest of the company, or commit to production. I don't see how Pijul features can remove the need for such lines of development.

I also don't see how it matters whether a branch is long-lived or not. What Pijul may help with is a (broken, IMHO) workflow of some Git projects where the long-standing branches are constantly rebased. This workflow is bad, but having branches in Git does not force you to (mis)use rebase.

I am not saying anything against Pijul, and maybe there is a better way than branches to manage multiple lines of development, but I'd like it to be explained. So far I cannot guess what it might be.

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

#176

Post by pmeunier »

exDM69 wrote: post #111
dooglius wrote: post #95

Earlier quoted context omitted.

The git behavior seems greatly preferable here. As mentioned in other threads, the notion of commutativity here is very weak and counterintuitive; it only seems to cover the applicability of an auto-merge heuristic, not any actual notion of correctness or semantics, so a human is needed to review the merge and re-test before anything can be known safe for pushing upstream. If anything, git is too lenient in allowing…

When the contents has a conflict, git and pijul behave similarly. When the contents are identical, but the order of commits is different, git will conflict and require manual resolution. Pijul will not. As you say, neither will automatically check for correctness and you should run tests and CI when merging. Pijul just removes the manual work when there is no conflict in the contents but the history is different.

> When the contents has a conflict, git and pijul behave similarly.

Not really: Pijul can record a conflict resolution as a patch, and apply it in a different context. Also, the conflict doesn't "come back", so you don't need extra hacks like rerere/jujutsu.

> Pijul just removes the manual work when there is no conflict in the contents but the history is different.

This is true, but could be confusing as our definition of conflicts isn't based on contents, but on operations, which is very different from Git (Git doesn't detect all conflicts).

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

#177

Post by IlliOnato »

manithree wrote: post #159
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/...

Thank for the links! I've looked at them, and while they gave me more and interesting information on Pijul, they did not explain how you can work without multiple channels in a realistic development environment. However, from these pages it appears that working with channels in Pijul is more cumbersome than working with branches in Git.

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

#178

Post by pmeunier »

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…

Oops, don't look at what we do! These repos have been used for dogfooding and bootstrapping extensively, they have the worst structures and aren't good examples of nice, clean workflows. The tool isn't really "experimental" anymore, its repos are still used for heavy experiments.

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

`pijul log --state` does that, and various commands (tags, fork) do it as well. Tags are due for a redesign, since they can be made much more efficient with a really cool new design, and make Pijul a perfect hybrid between patches and snapshots.

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

#179

Post by pmeunier »

ykonstant wrote: post #43
CuriousCosmic wrote: post #40

Earlier quoted context omitted.

Which tbh is a bad thing. Just because change a doesn't textually touch change b doesn't mean they don't interact. Unless your VCS is handling CI for integrating changes on push, you really need to pull down the upstream changes first and test them combined with your code before blindly pushing.

That seems like a very important point; how does pijul deal with such "effects at a distance"?

By not being a CI tool, nor claiming to solve such Turing-complete problems.

Pijul has a theory of textual changes, but indeed doesn't care at all about what you write in your files: that's your problem!

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

#180

Post by IlliOnato »

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…

Enable development that does not rely on a central repository. For some people/projects it's important, although these days it's a minority.
Post reply on HN