Alternative to git describe?

[marians]

I’m trying to prepare a pijul-pijul package for the AUR.
This requires finding out a unique identifier for the state of the source code.
As far as I understand it, the IDs printed by pijul log are the change IDs, which only point to a certain change, which in turn could come at a different position in my repo than in any other and thus cannot point to a certain state of the source.

So this is my question: Is there a (simple) way in pijul to refer to a certain fixed (or at least semi-fixed) state of the repo?
If that is not possible, then is there a way to list only the set of change IDs that are not depended on (i. e. a minimal set of changes to reach the current state)?

Thanks in advance!

[pmeunier]

This would be really nice, but it isn’t super easy. There are multiple options, among which:

• pijul archive
• tags (pijul record --tag)

At the moment, these things are not as fast as they could be, and quite far from the speed of Git. A few things need to happen before that can be done.

[lthms]

A list of changes with no reverse dependency could do the trick. Creating an empty channel and applying each of these changes would in practice reproduce the desire state, but said list can be very long as the repository grows. :\

Alternatively, the easiest way to do it is to start recording tags for release (something that will probably starts after 1.0.0 is released, as I understood it). Then, the hash of this change could be used in pijul fork --change and voila

[marians]

@lthms

A list of changes with no reverse dependency could do the trick. Creating an empty channel and applying each of these changes would in practice reproduce the desire state, but said list can be very long as the repository grows. :\

Yeah, that’s what I thought. The tag idea might work, though probably not for a package tracking the repo. The way these packages are supposed to work, they pull the current repo and build a package from it. But they need a version – in git, this is accomplished with git describe. My impression is this is only needed to be able to check whether two installations are (should be) the same or not.

I found pijul log --state. It sounds like it could do the trick of an equivalence check, but I’m not 100 % certain. What exactly is the state that’s output by this?

[pmeunier]

@marians

I found pijul log --state . It sounds like it could do the trick of an equivalence check, but I’m not 100 % certain. What exactly is the state that’s output by this?

A “state” is a cryptographically-unique identifier of a set of changes. It isn’t shown by default in order to avoid confusions: a very large number of Git users don’t understand that Git is snapshot-based, and seeing both change hashes and version hashes would probably be extremely confusing to them.

The cool thing about these states is that:

• They don’t care about the order of changes: in other words, if Alice has the list [A, B] as her log, and Bob has [B, A], pijul log --state will show the same logs.

• They can be computed incrementally: from the state describing [A], adding B to the state is in O(1).

[lthms]

So from my understanding, the state ID is indeed what you are looking for: if two repos have different states, then you know by construction that they do not have the same set of changes.

I guess we could provide a way to just output the current state of a repo (for now I guess the way to obtain it automatically would be to parse the output of pijul log?)

[marians]

@pmeunier , @lthms: Yes, I’ll use the state ID for now, it sounds perfect for this task.

Just a note for posteriority: I’m currently using something like pijul log --state | grep '^State: ' | head -1 | awk '{print $1}'

[boogerlad]

Very cool