I will write how I understand it, although I may be wrong. But I give it a try
The whole misunderstanding with Channels is based on two things.
Let’s try to deal with the first point. Lets change the name “Channel” to “Group” In the mathematical term this group is called “Set” what is just fancy word for an unordered collection of different “things”. In case of pijul those “things” are “changes”. Maybe you remember from elementary school or even kindergarten. Sets of apples and sets of pears ? I bet you do :)
https://i.pinimg.com/originals/4e/65/7f/4e657f12d581cc01c05abc7361babd96.jpg
This may seem trivial and funny. But as children, we attended a 101 set theory course, branch of abstract mathematics that pijul is based on.
But for the rest of this text we will stick to the word “group”.
So “group” is collection of results of pijul record
command, new “change” is being added to the group every time you invoke this command. Every Pijul repository has at least one “group”, and that group is called “main”. We can list those “changes” by invoking pijul log
. We can invoke pijul log
for every group we are working on.
What groups give us ? Well, it gives as that “change” can belong to multiple groups at once. So we have ability to group “changes” into different “groups”. Much like file can belong to different folders at once. Or more file like shortcut, because changes are not being copy but referenced, making them very light and smart. So we can create multiple variations of our repository where every “group” is containing different/same set of “changes” or unique ones that only belongs to particular group.
So our workflow could be as follows. We have three groups and some change represented by hash, lets call it “ABC”
Using
pijul apply ABC --channel new-features
pijul apply ABC --channel backup-version
We add “ABC” from “main” group to both “new-features” and “backup-version” Now by switching groups we can make two different versions associated with that “change”. Improving ABC creating new feature, by adding more “changes” to that group, and leave another group as backup or maybe where we do some additional cleanups in repository.
And Indeed this works as folders on steroids. Allowing to maintain multiple versions of the same project by creating different groups of “changes” So we can now do all crazy stuff like show difference between two groups, apply one group to another in future versions of pijul maybe produce new group made up of differences between two, or produce new group where “changes” are unique to both ? Who knows. I think any operation that can be represented on a Vienna diagrams could potentially be performed in pijul in future.
Now second point. Why groups and not “branches” ? Because there are no git like branches in Pijul. In fact there are no need to have one. The only similarity with git branch is that they store information side by side separately. That’s the “bit like branches” part.
Branches form a new tree branch with link from one change to another and another and another. Where end user in git needs to maintain that complex data structure. Decide whether merge branches or delineate new path in that tree, or connect one change to another in other way. But in git that is needed, because changes depends on each other. In pijul every little “Change” is independent you literally slam changes together and and conflicts are handled manually as they are nothing abnormal in workflow. Math will do the rest and take care that everything will be fine. There’s is no need to involve here with git’s complexity. Pijul is very elegant and simple tool.
I know that Channels bring to mind some kind of funnel or queue, something dynamic. I have cought in that mental spinning wheel myself. I assume this has to do with the category theory and functors that map one category to another. Such functors are represented by arrows on the diagrams. Maybe that was where the name came from? pmeunier is a scholar, where he used very specific language. Maybe that was his first idea for the name.
Final word: So called “Channels” are more like sophisticated versions of bags that some complex magical ideas. Flat and boring bags of “Changes”
So “group” is collection of results of
pijul record
command, new “change” is being added to the group every time you invoke this command.
Well, sort of. I gave a test case for showing that the add
command is per channel, even though that command has no channel options. Because of this, the ls
command is also per channel.
In pijul every little “Change” is independent you literally slam changes together and and conflicts are handled manually
Not really. It’s very difficult to make an independent change. You have to add a new file usually, to be independent. And files are tracked per channel.
I have read the Readme several times and always get confused by the channels section:
To me, saying that a channel is a set of changes means that you can have a line that is in two different states by putting it in two different channels. But that is more like a branch in git, because saying that resolving a conflict in one channel solves it in other channels means that the change has only one state. So what is a channel?
I suggest that this section’s wording is changed to more clearly explain the difference with branches. Only the first point actually addresses difference to a branch.