Hacker News Reader

Comment by zck | Hacker News Reader

> 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 someone else's eyes on it, maybe you just want to back your current state up on a remote server because your laptop is going to explode.

Am I misunderstanding, and Pijul manages that without channels? Or is there a common case git branches are used that I missed?

View on HN

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.

So we have a git branch v1, and a git branch v2, and sometimes we pull commits into both, and other times just one. How does pijul manage that without using channels?

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.

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.

There are (unfortunately) a lot of git repositories with multiple long-lived branches, often to track what's released in different environments. Unfortunate because it leads to a _ton_ of merge conflicts and uncertainty about what code is live in what env.

One of the most popular of these flows was popularized under the brand "Gitflow". Atlassian has a detailed, and critical, writeup of that here: https://www.atlassian.com/git/tutorials/comparing-workflows/...

Reply on news.ycombinator.com