Disambiguating short IDs that conflict with (plausible or actual) names for bookmarks/branches in projects?

[lgarron]

I'm trying jj, and trying out this shell prompt with jj status info. I was very confused to see the following:

This looks like it's telling me that I'm on (or close) to a bookmark named xml. I was confused because there is no use of XML in the project, but there are a lot of old branches and perhaps I typed something wrong. Or maybe I wasn't aware of some unexpected interaction between tools and an xml bookmark/branch was introduced to the project.

(Note that 18 in the screenshot is actually a short ID for a commit, not a number representative of anything. That also has some potential for confusion, but I'm a little less worried about it in this case.)

Turns out that, nope, xml was just the prefix for a changeset ID:

It seems that pun is also a short ID in that screenshot (a with a longer prefix of punk!), as well as my and yo. Those are less plausible names for me, but it does highlight that the arbitrary nonsense of short IDs can form too much sense by accident.

If I run jj bookmark set xml, then the two xmls will both show as purple, which further conflates them:

I now have no idea which one would be chosen by a command like jj new xml. At the very least, it would be useful for short IDs to avoid collisions with current bookmarks when computing the prefix length.

This isn't an issue in git because:

• Most tools print IDs with at least 7 characters.
• 10 of 16 characters are numeric, making (non-1337) words less likely.

This isn't jj's fault per se, but even as someone who has extensive experience with version control I was thrown off by this. And I think even if I get a lot more experience with jj, I would still pause for at something like this in the future.

I think it certainly has the potential to cause confusion for others as well. To me, it has the kind of "oh yeah, that's confusing the first time you run into it, but you get used to it" vibes that I think think people find unappealing about git compared to jj.

But it might be possible to do something about this. For example:

1. At one extreme: The hash could be specifically tuned to avoid producing words in a dictionary. There is some precedent for version control systems detecting a problematic hash, albeit for unrelated reasons: SHA-1 is no longer collision resistant, but there is a heuristic to tell whether a hash being computed for a given input is the result of intentional collision. This heuristic was published along with variant of SHA-1 (sometimes called SHA-1CD) that computes an alternative hash in such cases, and git has used this since 2017.
2. More easily: The short IDs could be extended by a letter or two if they conflict with common short words in the dictionary.

Obviously, there is no objective list of words that can be used. ¹ Common words vary by language and region, and change over time. Words . And even an acronym like ymmv could be considered to look like something intentional rather than random. However, the second approach above can adapt to a changing (or even locally customizable) set of words.

EDIT: I wrote the above assuming changeset IDs are produced by a hash. But thinking more about how jj works, that might not be the case? In which case, rejection sampling for changeset IDs might actually be easier than I was thinking.

Footnotes

1. If it was up to me, though, I'd start with an English dictionary + a scan of GitHub for common branch names and variable names in code. ↩

[cenviity]

Related: #5837

[lgarron]

I also just got a changeset short ID of nul, which is certainly suggestive but also means nothing¹. 😆

Footnotes

1. I mean, it literally does mean nothing. But it doesn't mean ␀. ↩

[jennings]

I'm sorry, but I find this problem hilarious and want to keep it as an Easter egg.

Anyway. The priority is well-defined: Matching tag and bookmark names will be chosen over change IDs (and commit IDs).

With that in mind, maybe the logic that determines short change IDs (and thus what is shown in purple) should be aware of bookmarks and tags that might conflict and consider those names like "xml" already used.

UPDATE: Oh, I just scrolled right past the link to #5837 #2416 above. That's exactly what I was thinking.

EDIT: I wrote the above assuming changeset IDs are produced by a hash.

They are just opaque byte sequences displayed in hexadecimal. But, instead of using the alphabet 0-9a-f, they use the alphabet z-k.

There are times where jj uses a hash function to generate the byte sequence: When you import a commit from Git, the commit ID is deterministically used to create the change ID. This means if you clone a repo twice, you get the same change IDs. But those change IDs are just stored as opaque values and not used to verify anything.