Preserve jj change ids when using `git test fix`

[TeofilC]

jj now supports putting the change id in the git commit header.

I would like to use git branchless test fix along with jj, since jj currently lacks a comparable feature, but branchless currently removes the change id it seems.

Would it be difficult to change branchless to keep the change id? I would be keen to help with this if it's a reasonable first contribution.

[claytonrcarter]

I’m not very familiar with jj, but I’m supposed to hear that test fix is rewriting commit messages. (Then again, I don’t use test very often either. 😁)

Can you provide an example of a commit message that you start with, the actual message you get, and what you would like it to look like? Either here or as a PR with a failing test.

[TeofilC]

rewriting commit messages

The terminology is a bit confusing but this isn't part of the commit message.

I think each commit has a list of headers and jj added a new one that isn't known by git. Some git commands preserve unknown ones while others don't.

[TeofilC]

Here is an example:

❯ git show --format=raw HEAD
commit 213655a906a25d6a734b1420d4ae79517b1cf72e
tree 557b23f7ee9fe5d2b273b85f12d228778e07b64f
parent ddfbeea38b924d32bc42a0bdaf390f84fd632142
author Teo Camarasu <teofilcamarasu@gmail.com> 1749639685 +0100
committer Teo Camarasu <teofilcamarasu@gmail.com> 1749639685 +0100
change-id lmtmkszwnvrvslmxzynskxwqkllylszx
❯ git branchless test fix -f HEAD -x 'bash -c "echo foo>>asdfasdf"'
...
✓ Passed (fixed): 213655a Test
Ran command on 1 commit: bash -c "echo foo>>asdfasdf"
1 passed, 0 failed, 0 skipped
...
❯ git show --format=raw HEAD
commit bfee756030070a638c567791bf9cc6d20c686bfa
tree d71f8c0618bc046d2baeae8361b5aa7078d60f46
parent ddfbeea38b924d32bc42a0bdaf390f84fd632142
author Teo Camarasu <teofilcamarasu@gmail.com> 1749639685 +0100
committer Teo Camarasu <teofilcamarasu@gmail.com> 1749639849 +0100

    Test

Note that the change-id header has been removed

[claytonrcarter]

Thank you for the context. I see what you're talking about. Here's some quick research:

jj seems to be using gix/gitoxide while we use git2. They are adding change-id here: https://github.com/jj-vcs/jj/blob/main/lib/src/git_backend.rs#L1297-L1322 and git test is using git2::Repo::commit (via our own create_commit wrapper) here: https://github.com/arxanas/git-branchless/blob/master/git-branchless-test/src/lib.rs#L1985-L1992

A quick survey of the git2 docs suggests that it doesn't support adding/editing headers, though is does seem to support reading them. (I only scanned the docs quickly, so it is definitely possible that I'm overlooking or misunderstanding something.) gix seems to support headers natively.

If it's true that git2 doesn't fully support headers, then we're at a bit of a loss. If it does and I just missed it, then this may in fact be a good first issue: it would involve reading the headers from 1 commit and passing them in to create_commit, and then doing the dirty work of writing them to the new commit in there.

[arxanas]

Thanks for reporting! It's definitely desirable to preserve the change IDs, and preserving commit headers wasn't a consideration when I originally wrote git test. (Since then, it's also become apparent that it's worth considering commit signature headers, which I didn't do either.)

I think there's another potential issue: jj won't know that the old versions of the commits have been abandoned by git-branchless. The result is (should be?) that jj sees both versions of the commits. Once we start preserving the change ID, it should start reporting the commits as divergent, which is suboptimal/annoying, but overall a better state of affairs.

This is a similar issue in spirit to jj-vcs/jj#6724, where rewrites occur outside of jj that it doesn't know about. IIRC there's currently no way for git-branchless to notify jj of a rewrite that it performed.

Note: jj will actually handle abandoning the commits if the result of the rewrite on git-branchless's side also causes a branch to be updated, because it will import the new locations of the branches and hide the commits pointed to by the old locations of the branches. So it happens to work in branched workflows, just not branchless ones.