FR: Command for resetting change ID

[scott2000]

Is your feature request related to a problem? Please describe.
If there are multiple commits with the same change ID and I want to keep both versions of them for some reason, it can be difficult to resolve the divergent change ID. I think it would be nice if there was a command that just replaces all commits in a revset with identical commits, except with new change IDs.

Describe the solution you'd like
I'm not sure what a good name for such a command would be, since jj reset-change-id seems too long. Maybe it would be good to have a general command jj reset that takes different flags depending on what needs to be reset:

# Reset change IDs of commits
$ jj reset --change-id <REVSET>
# Reset author name and timestamp of commits
$ jj reset --author <REVSET>

This might be confusing with git reset, so it might not be a good idea. I do feel like this would be a better place to put "reset author" though, since the current jj describe --reset-author feels like an unintuitive place to put it.

Another option might be a change-id subcommand, but I'm not sure if there's any other operations on change IDs that would be useful. Maybe swapping change IDs could be useful (e.g. if jj split left the change ID on the wrong commit), but that seems like a weird solution.

Describe alternatives you've considered
jj duplicate followed by jj abandon of the original commits works. This could maybe be done with an alias if aliases could execute multiple commands and take arguments to pass to each. Or maybe a new option like jj duplicate --replace <REVSET> could duplicate the commits, but automatically abandon the previous versions and rebase their descendants onto the new commits.

[mati865]

How about jj rehash, jj reroll (this one might not be so obvious), or perhaps something else that intuitively means SHA/ID?
I suppose it should be configurable with flags to reroll only ID, only the hash or both.

[scott2000]

Those could be good names!

I think it is technically not possible to modify the change ID without also modifying the commit ID because of how the change ID is stored for the Git backend (I think if you try it, jj will decrement the committer timestamp to cause it to have a new commit ID, but I could be wrong), so it would probably have to update the committer timestamp like the other commands which modify commits do.

[mati865]

I don't know jj code, but I've assumed it stores references to Git commits and it'd be possible to only recrate the reference.
Having to change both ID likely won't be a problem; I just imagined it'd be neater if somebody wanted to change only one of them, but I likely overengineered it, and nobody would care.

[joyously]

If there are multiple commits with the same change ID and I want to keep both versions of them for some reason, it can be difficult to resolve the divergent change ID.

Is it really the change ID that is divergent? It seems like the change ID is the thing being managed by the tool, so there are commands to manipulate commits that comprise the change.

[yuja]

I think it is technically not possible to modify the change ID without also modifying the commit ID

Correct. "commit ID" should be considered a content hash including "change ID". The change ID isn't actually stored in Git commit object, but changing it without updating commit ID would lead to internal data inconsistency.

Regarding command name, I feel reassigning change IDs is quite different operation than resetting author or description (even though the underlying representation is similar.)