Continuing the discussion from Phenomenological Pijul (or Pijul from the outside):
The OP had two questions:
- How to work on multiple features/bugs at the same time without using (named) channels?
- How does this integrate into a continuous integration system?
As mention in the other thread, a channel is the means from which to create a working tree through the use of a concept called state. So, whenever you need to manifest your wisdom into a working tree, you employ a channel. (Maybe, technically, there are other ways, but this is the intended interface.)
Q 2. How does not using channels integrate into CI?
It doesn’t. When you want to kick off the CI runner, you would create a special channel (that the CI can pick up on) and push all relevant changes to that channel. All dependent changes get pushed as well, resulting in a final state. The CI runner manifests this state into a working tree and works on that data.
This is how the Nest works. Each discussion represents a special channel named “<colon><discussion-number>”, e.g., :756 for discussion 756, which you can push/pull changes to/from. A CI would pick up on these channels and test the state that results from merging a particular base channel (usually main) and the patches in the discussion.
Q 1. How to work on multiple features without using multiple channels?
By above supposition, always use at least one channel. Thus, the question is about not using multiple channels.
Small recap about the meaning of channels, because it’s important to fully understand them. Channels contain changes in a particular order (the log order). Any collection of changes form a particular state. The order is technically not important (because the application of independent changes is commutative) but may be of high importance from a user’s perspective to “go back in time”. The log order fully determines to which states a user can immediately go back to. E.g.:
Change TWPJXHAFKIGDWPYUW2DUJZZEMRG743BHJ3MIMHD6QFRT4NQG42LAC
Author: spacefrogg
Date: 2023-05-09 10:23:34.463488474 UTC
State: MKROSKG5H45YIRSOJBWNSVEBBHMP3EHVY2SBGEISBKY7NJZP2MIAC
added a
Change 2AEC5EQWNDITJLMEBP7BGLD5EMA7KSC5K7OHNRLQNNKXWE4DAF7QC
Author:
Date: 2023-05-09 10:23:37.240641887 UTC
State: 3R7WEC7HIOGPOJMQYSVJNQAPAX5NXK6TEURJYWDKR2ZL6EFQGOLAC
As you can see, you can reach two states in this log-ordered channel, MKR and 3R7. Would these two changes be independent, you could not immediately reach the state that only contained the change TWP but not 2AE. The reason is purely the log order.
The current state of the channel is always the state at top-most change in the log (here, MKR) and will be the same for all log orderings of changes. This means when you and a collaborator have pulled-in the same changes in different order, your logs will look differently and intermediate states will be different, as well, but the current state at the top-most change will be the same again. See Move through history for details.
Now, because the application of independent changes commutes, pijul opens up new ways of modifying your repository state. While in git et al. repository state is a linearized set of commits, in pijul it remains a graph with multiple endpoints, called the independent changes. Like in git, in pijul, changes know about their dependencies. So, when in git you need to know a single commit hash to identify the complete repository state (because you can implicitly trace back the dependency chain up to the root commit), in pijul you need to know all independent changes and can retrace all other changes from there. Technically this means, the minimum set of changes that identifies a particular state is the set of independent changes (not all changes).
Finally, to the initial question. Working with multiple features means working with these independent changes. Right now, pijul does not have any supporting tooling for this except one. When you know that a particular feature is identified by the independent change ABCD, it is enough to push ABCD to another repository and pijul will make sure to also push all necessary dependent changes as well.
Currently, it does not help you cutting out a sub-graph of changes that only influence a single independent change (or a named set of them). You have to shave of that sub-graph one change at a time or name all the right changes at once.
Also, there is currently no user-facing tooling to help you visualize the influence of a change downstream. You would need this to efficiently identify the independent changes that form a “feature” looking from an intermediate change.
There is currently no tooling to identify independent changes in the log or to list only the independent changes. This might be interesting to identify the “features” that currently occur in your repository.
So, right now, you are left to the following approach. As long as two features (or bugs) touch separate files, you are good to go. You can look up the log of changes touching particular files and thus recreate the list of changes that make up a feature/bug. For pushing, you only need to know the last change. For cutting them out of your tree, you would need to generate the list with pijul log --hash-only -- <file>. And unrecord this list of changes. This might still fail when a changes touches more than your intended set of files, thus creating interdependencies to other changes. But this is an inherent feature of version control. Unrecorded changes are not lost but you would want to keep them in some other channel or repository for easier retrieval.
When it comes to the claim that “channels are not branches” or “channels are not so often needed”, it means the following. Suppose a collaborator has written a feature you want to try out. In pijul you can just pull in the feature into your current channel and throw it away later using above approach. It does not involve creating a new channel just for trying out somebodies feature.