Looking in the Pijul source code, it appears that “pijul record --tag” does not currently do any thing different from “pijul record” as the boolean flag “tag” is never checked for the the record command’s file.
So, Pijul currently lacks tags in the sence of “git tag”.
So lets discuss what “tags” should be in Pijul when they get implemented.
When Pijul version 1.0.0 is fully released, more important that having tags is making sure that support for tags can be added later without having to change how repositories are stored on disk.
I will be starting things off by talking about “tags” as they exist in Git and some related topics.
“Tags” in Git mainly provide a way to associate a name with a particular “snapshot” of the repository so it can be found again later, either by humans or automated programs that look for particular tags.
Pijul does not keep “snapshots” like Git, and recreating a specific state is - from what I have read -
currently a expensive process.
So for “tags” to be very useful in Pijul beyond just assigning a name to a state, they would need to be associated with data that allows the state to be restored more easily.
When a tag is attached to a snapshot, it generally means there is some expectation that particular state will be desired again.
Since states with tags are more likely to want to be recreated, even if the process of recreating a state in general gets faster it would still be desirable for “tagged” states to be even easier to recreate if possible.
Within Pijul as it currently exists, there is a construct that exists to help with restoring a state. That is channels.
To implement a basic but useful version of “tags” based on channels would be a matter of having “read only” channels that cannot be switched to with "pijul channel switch ".
The “read only” channels could then be used to create new channels with "pijul fork --channel ".
In the long run though, a minimal version of “tags” may not the best approach.
It somewhat depends on how channels are implemented, and I have only taken a glance at their implementation.
Looking at the data structure for Channels in libpijul, they look to be fairly hefty.
When Git is used as a “mono repo” containing multiple related projects, a commit may have multiple tags for each of the sub projects that has a new version.
If channels are potentially very large in the repository, then it should be considered if they should be split up into a “state snap shot” and a reference to the snap shot to reduce the cost of having multiple tags and or channels that all share a state.
On the topic of states that are more likely to have reason to be recreated besides those with tags or are the current state of a local channel are “remote” channels that are the states of channels in a remote repository. Currently, Pijul only has a concept of ‘local channels’.
“Remote channels” that track the state of the remote are not needed for Pijul to work correctly when syncing changes.
They would be for easily switching to the state of the remote and for looking at the difference between the remote and local states.
In terms of how they function, “remote channels” would be similar to “tags”. The difference would be that the “remote channels” would be created, deleted, renamed, and “moved” automatically when pushing and pulling to / from a remote.
One last thing to consider is if it would be desirable to have “remote tags” that represent the tags that are known to exist in a remote repository. Git does not have a concept of “remote tags”, so clearly it is possible to do without them. The question is, would having a dedicated concept of “remote tags” make the book keeping involved in ensuring local tags and tags on the remote are synchronized correctly easier on users.