I’ve tried several times to understand what a channel is, but still come up short. I think there is something about “state” that isn’t defined anywhere.
Hopefully, someone can explain it, and update the readme
https://nest.pijul.com/pijul/pijul/discussions/661
1 Like
Channels solve the following problem: you want to maintain multiple versions of the same project, and share as much as possible between the versions.
Channels can also be forked efficiently.
You can’t not use channels if you use Pijul, since patches are applied to a default channel.
2 Likes
Thank you for your response, but it doesn’t actually explain anything.
It only made it more confusing in the sense that a version control system has to be told to maintain multiple versions manually.
1 Like
Ok, I don’t fully understand your question then. What are you trying to do?
Also, Pijul must indeed be told about multiple related versions manually, it doesn’t guess anything.
It’s not a matter of trying to do something. It’s about understanding how to use Pijul.
Part of my confusion comes from the explanation in the readme being a comparison with Git, which I don’t really use.
Pijul and its features should be comprehensible by themselves, not as a comparison.
If there is a default channel, say so. Does that even mean anything?
What is stored in a channel? How is that different than a change?
Is there a limitation to a channel?
When you say that merge conflicts are solved everywhere, how is that keeping multiple versions?
How would I know if I should use a different channel? (what criteria)
1 Like
Channels are what your patches are applied to.
There is a default one, in the sense that a channel is created when you do pijul init. Without one, you couldn’t apply patches. Channels store the log of your patches.
I’d like to know whether you actually tried to use Pijul, since I thought channels were particularly intuitive, since you don’t have to think about it at all.
I thought they were applied to the pristine. Are you saying channels are the implementation of the pristine? This is a bit confusing, because pristine seems singular and channels are multiple.
This sounds more reasonable, and can be tied back to some concept of “state” that is mentioned in passing, I think in one of the command help texts. At the same time, it adds a big cognitive burden for using channels, for getting all the right changes into the appropriate channel. This sounds like managing SVN branches with fewer visuals.
From the pijul help text, I infer that the working tree is modified with some of the channel commands. Is this correct? It would be great if that were made clear.
Yes, I have tried a few things. Usually when I do, I report a problem. And I’m still waiting for more commands to be on par with Darcs, mostly show. Since you write about channels versus git branches, I guess that’s why it’s intuitive to you. I don’t like git, don’t use it much, and don’t like git branches because of the mental overhead of colocated versions.
The help text should be enough to use the tool, but it doesn’t say enough about side effects or what’s actually happening internally to figure it out.
“The pristine” is a bit vague. The pristine directory contains one or more channels. If you don’t like them, you can use Pijul like Darcs or SVN. Other users believe they can’t live without something similar to Git branches, and may find channels useful.
The main reason I wrote them (and spent years writing and polishing Pijul’s backend, called Sanakirja) is to make it mentally easy for the majority, which is sadly mostly made of Git users, to switch to Pijul.
I agree this would be useful, but I’m not sure how to write it yet.
What happens internally is significantly harder to explain than in Darcs or Git, unfortunately. This is often why the documentation is sometimes hard to write: in this project, even things that are intuitive and simple aren’t easy to implement under the hood. This is mostly because of performance constraints: you can’t claim to write a version control system these days if you aren’t competitive with Git on that metric.
I related to these questions and I appreciate these efforts to make explanations and docs clearer, which I think has a big impact. And yes that’s not easy. What about something along the lines of
“In many version control systems, including Git, a repository can contain multiple branching lines of history, called branches, and you can quickly switch to a different branch within a working copy, to see files as they are in that branch. This is convenient and helps make rebuilding efficient, since build artifacts can be reused. Pijul also supports these, calling them channels. Run pijul channel to list channels; there is always a default main channel, and you can create more with pijul channel new NAME, switch with pijul channel switch NAME, etc.”
And what about actually just renaming them to branches ? It would demystify this concept quite a lot.
[Already covered on Channels - The Pijul manual , but the first section there might be a bit too technical for new users, for them perhaps it’s more helpful to emphasise the similarities and practical use cases.]
I didn’t mean to explain the code. I simply meant to state what concept is affected by the command. Currently, the channel help says
Manages different channels
The channel command actually lists the channels, and it’s the subcommands that manage them. But it could mention colocation and that the working tree is affected (if it is), or say what you said earlier about “Channels store the log of your patches”, but a little clearer. One thing that stands out to me is that you can delete a channel. Does that delete any patches or log entries? Most VCSs don’t forget anything that you do, even if you delete or revert or reset, etc. These are the details that are needed in the help, not how the code is written.
I think we’ve had this discussion.
I also don’t like fork for a channel, when it’s usually known for a repo.
I think we’ve had this discussion
Would you mind summarising it, for newcomers like myself ?
Also, how does my draft sound to you ?
Here’s one discussion here: Calling branches "branches" is misleading
And on Zulip:
pijul channels vs. git branches
Getting all the changes in a channel?
branching
branches and channels and unrecord
Your draft is okay for the manual, but it’s the help text that I think is more important. Of course, Git and Bazaar both have extensive help text, so Pijul could also. No need for a manual then.
I just add a little explanation suggestion about channels - it’s just a chain of patches.
It’s not. A channel is a set of patches.
Okay, it’s set. What’s difference between set and chain? I think it’s about reordering ability. So, we can get two channels with exactly same patches, but in different ordering of some patches. Well, okay, I agree
The main difference is about the operations. A chain/list implies that the only operation you can do is on the first element (youngest patch), whereas a set allows you more possibilities.
1 Like