Oh. So the scope of change_id is just “active changes”, not “all changes”. I kind of assumed that a combination of base32 having larger … base, and maybe matching on the first (depth wise) was used, which is kind of similar, but I now understand that JJ is calculating actually unique prefix, just in a subset of changes. In my idea, I guess saying which of changes is actually “earlier” and which “later” might be a problem.
^ This is also a key point. Change IDs are rendered in “reverse hex” notation, which is normal hex notation using the alphabet z..k instead of 0..9a..f. This makes it easier to differentiate the two types of ID.
All changes get a change ID, and JJ does calculate the unique prefixes for all those IDs when they get rendered (using the main indexes as described in the “Indexes in Jujutsu” section). It can do this efficiently because it stores all the IDs as a sorted list and can therefore see which IDs neighbour any given ID.
But it then also has a separate index for the active changes, that’s much smaller. So any change gets looked up first in the “active changes” index, then in the main indexes if it’s not found.
If somebody notices that their change_ids are >4 chars, I’d recommend actually tinkering first with revsets.log instead of revsets.short-prefixes. If the former is too broad, it cannot be really fixed with the latter.
Oh. So the scope of change_id is just “active changes”, not “all changes”. I kind of assumed that a combination of base32 having larger … base, and maybe matching on the first (depth wise) was used, which is kind of similar, but I now understand that JJ is calculating actually unique prefix, just in a subset of changes. In my idea, I guess saying which of changes is actually “earlier” and which “later” might be a problem.
Change IDs are actually base 16! They just use a completely nonoverlapping alphabet to commit IDs.
^ This is also a key point. Change IDs are rendered in “reverse hex” notation, which is normal hex notation using the alphabet
z..kinstead of0..9a..f. This makes it easier to differentiate the two types of ID.OH. I’ve never noticed.
It’s kind of both.
All changes get a change ID, and JJ does calculate the unique prefixes for all those IDs when they get rendered (using the main indexes as described in the “Indexes in Jujutsu” section). It can do this efficiently because it stores all the IDs as a sorted list and can therefore see which IDs neighbour any given ID.
But it then also has a separate index for the active changes, that’s much smaller. So any change gets looked up first in the “active changes” index, then in the main indexes if it’s not found.
If somebody notices that their change_ids are >4 chars, I’d recommend actually tinkering first with
revsets.loginstead ofrevsets.short-prefixes. If the former is too broad, it cannot be really fixed with the latter.