Discussion seed: Using ChangeIds as identifiers in the CLI

[Caleb-T-Owens]

Byron and I landed reverse hex change ids in #11788, and I just wanted to open pandora's box and start the conversation around using them as identifiers in the CLI.

This is really just a bit of a brain-dump of some thoughts I had. I'd love to discuss this more.

ChangeIds in GitButler

GitButler now reads and writes the change-id header. It's generally been agreed between JJ, GB, Gerrit, and co that it should be a 32 character "reverse-hex" value.

With that said, a user or another tool could put whatever arbitrary data they want in there.

To GitButler, the change-id's value is completely transparent. When cherry-picking, we take any contents of the old identifier and will write it verbatim into the commit we are writing. This is hopefully the most compatible way of working with other tools.

Things to consider when using ChangeIds as identifiers

Within a workspace there is no guarantee of change-id uniqueness. If a user cherry picked a commit twice into the same branch, you would have two commits with the same change id.

We also from an aesthetic standpoint I think always want to display change ids as reverse hex.

A starting point for finding identifiers for the CLI.

I've probably not found all the cases, but a starting point for an algorithm might be as follows:

• Collect all commits in the workspace
• Any commits without ChangeIds will just use their oid as their identifier
• We then collect all the ChangeIds & normalize them if they are not reverse hex by sha-1ing the value & converting to reverse hex
• Any commits that share a common change ID will both use their oid as their identifier
• The rest of the commits will use their normalized changeIds as their identifier.

The reason I suggest we use the oid of both commits in the case of a conflict is because I'm not sure there would be a stable way of picking which commit should use the change ID, and could potentially cause more confusion.

[jonathantanmy2]

Some other possible points for discussion:

• Currently we have 2 namespaces of CLI IDs: commit IDs (hex characters only) and stack+branch+file+hunk (everything that cannot be confused with a commit). As far as I can tell, this proposal will further overload the latter namespace. I'm wondering if we should have more demarcation of the various namespaces (e.g. one idea I had in the past was to make file CLI IDs of the form <commit CLI ID><[g-z][a-z0-9]?> or <unassigned area/stack CLI ID><[g-z][a-z0-9]?>, so that if we see an ID like that, we immediately know that it's a file ID.
• This means that we have to parse commits every time we parse a CLI ID (since the change-id is a header), but we may be able to save work with some namespacing (as in my point above).

I've probably not found all the cases

I don't know if a user would want to lookup an upstream commit by change ID (say, they saw it on Gerrit and want to check it out locally), but if they do, it won't work with the current proposal. (I can't think of any good solutions.) Otherwise what you suggest looks good, including falling back to the commit ID if there's a conflict with the change ID.

[Byron]

Thanks for bringing this up, I also think that having JJ-style stable'ish IDs would be a benefit. And now that we have their change-id, it's in the cards as well.
To me all this also seems sound, and I second @jonathantanmy2 here about CLI ID namespacing.

This means that we have to parse commits every time we parse a CLI ID (since the change-id is a header), but we may be able to save work with some namespacing (as in my point above).

We do so at about 120k commit/s/core on a modern CPU, so I don't think there will be a performance issue. I also believe we will have a per-commit cache to store expensive data like changes and diffs, and we might throw in the Change ID to make this query a DB lookup most of the time in future.

So from my point of view, there doesn't seem to be a technical hurdle.