I recently started to take a closer look at pijul, and soon started to wonder how to refer to a particular set of patches unambiguously (as in, some kind of merkle root of just that set). It seems like tags are what I’m looking for, but then, they’re just patches – if I’d like to discover what tags a repository has, I need to grep through the log (and know which branch to look).
Would it be conceivable to have pijul maintain an index of tags, and surface that in the CLI? Or is there some other way to do this, which I’m just missing?
In the future, when our disk space usage problems are fixed, we could imagine using branches as tags.
Interesting. What would that entail? Is your remark about disk space
usage related to how you’d envision this to work, or more about
current priorities?
What I’m after is a way to quickly check if a remote’s view of a
branch is the same as mine, fetch only a known subset of patches, but
also to be able to verify that the received patchset contains what I
was expecting (and nothing else). I realise this sounds like git
commit hashes, but I don’t see a reason it couldn’t work with just
sets – there are unordered merkle tree constructions.
I would usually try to push and try to pull from/to that branch, but I realise it’s not ideal. By the way, a good contribution for right now would be to write a test with an imaginary command that does what you want here, and we can try to either implement it, or help you implement it if you’re interested.
That’s what tags are for, but the “nothing else” part is still not super clear in Pijul. My suggestion of lightweight branches is that the current “wisdom” about branches is that they can become so heavy that we only use them like we would use “long term branches” in Git. In the future, branches will be very light sets of patches, so fetching a tag might create a temporary branch containing nothing else, at a ridiculously low cost.
