Pijul is great at managing different versions of a piece of software, e.g., a free, premium and pro version in Mac/Win/linux (just an example). Each version has a channel, and features (i.e. pathces/changes) can be added / removed from them easily (pijul apply).
A GUI could highlight this benefit in a table-oriented GUI. The table would have:
- one column per version
- one row per change / feature
Each cell would show whether the version has the feature.
Clicking on a cell would add/remove the feature from the version.
Much simpler than having to merge a change in every git branch !
Has this been discussed before? Could such a tabular view be added to Nest? It would greatly show the power of pijul, I would think.
That sounds great for a marketing page, but Pijul doesn’t really work that way. I think if you tried it, you would find that your features (patches/changes) get tied up with dependencies.
This is very true if you use a single channel, but I believe @pcarbonn’s suggestion already requires a fair amount of planning to decide which feature goes into which branch. In that case, you can work around dependencies by using channels wisely. This requires a bit of discipline, but still much easier than rebasing and cherry-picking commits in Git (or other 3-way-merge-based systems, even when wrapped in UIs), since you can share commits between the versions.
Indeed, if you add a feature to a channel, all its dependencies will also be added; otherwise the feature would not work anymore in that channel.
But that should not be hard to handle:
- first, you select a row / feature: its dependencies and the changes that depend on it are highlighted in the table;
- if you add it to a channel, all its dependencies are added.
- if you remove it from a channel, all the changes that depend on it are removed.
In any case, a first step could be to extend pijul log to allow such a table-oriented display for 2 or more selected channels. That would already help marketing pijul by illustrating a major use case: managing different versions of a piece of software.
I believe what @joyously meant wasn’t about implementing the GUI, but rather about generating the patches. He’s right in saying that this isn’t trivial (what I interpreted as “requires strong discipline”).
Right now in Pijul, if you try to remove (unrecord) a change, it will tell you that there are dependencies and not do it.
Please see Dependency Graph topic and try the script there so you can see the HTML version of the dependencies and how intertwined they get.
What do you mean by generating the patch ? My understanding is that you develop a feature in a channel, and record it: you now have a change/patch. You then use the CLI / GUI to add it to other channels (and resolve conflict if needed): pijul will also add all the dependencies. This should work out of the box, isn’t it?
It’s unfortunate but acceptable that removing a patch is only possible if no change in the channel depends on it.
The dependency graph is interesting, thanks. I fail to see how it invalidates the idea, though: maybe I need more practice with pijul to understand it. If the idea is invalid, it would be a pity because it would invalidate a great use-case for pijul, AFAIC.
Still, one concern I have is that a feature is typically made of a set of related changes. So, implementing the idea may require the capability to create and manage such sets. This abstraction would reduce the complexity for the user.
Such sets are different from channels in that they are not “rooted”: a change in it may not have all its dependencies in it. (In a channel, all the dependencies of a change are also in the channel, allowing the generation of the pristine code. Not so with a feature set, although one can always extend it by adding the dependencies)
PS: I have another use-case based suggestion to make. Do you prefer that I do it now, or later when Nest/WASM is developed? Also, it may be useful to have a “Suggestion” category in discourse.