On 2026-02-23 at 19:41:44, Justin Tobler wrote:
> Greetings,
> 
> With c20f112e51 (fast-import: add 'strip-if-invalid' mode to
> --signed-commits=<mode>, 2025-11-17), it became possible to remove
> invalid signatures from commits via git-fast-import(1) while maintaining
> valid commits. Building upon this functionality, a user may want to
> re-sign these invalid commit signatures. This series introduces the
> `re-sign-if-invalid` mode to do so accordingly.
> 
> The newly added mode in this series currently ignores
> `extensions.compatObjectFormat` when generating the new signatures. From
> my understanding, to generate the compatability structure would also
> require us to reconstruct the compatability object for the object being
> signed. I think this would be possible to do, but would require getting
> the mapped OIDs for the commit parents and tree. I'm not competely sure
> of a good way to go about this yet though. I'm also not completely
> certain if this is something that should be adressed as part of this
> series, or could be done later down the road. So for now I've opted to
> delay its implementation. I'm open going down the other route if that is
> preferred though.

There's an API for converting object IDs to another algorithm:
`repo_oid_to_algop`.  If you want to convert a non-blob object, there's
`convert_object_file`, which will serialize the object in the other
format (blobs are invariant in the hash algorithm transformation, so
converting them is not necessary).  Those are present right now in the
codebase and using them would be a good idea.

If you want to test your code in interoperability mode, you can rebase
onto the `sha256-interop` branch of https://github.com/bk2204/git.git
and run with `GIT_TEST_DEFAULT_HASH=sha256:sha1`.

If you're _not_ going to implement that in interoperability mode, then
I'd rather you just die in that case so that the test fails and then I
or someone else will fix it.  `extensions.compatObjectFormat` is
presently experimental and the data formats will change, so nobody
should be relying on it working as it stands right now.  There _will_ be
more compatibility breakage coming in future series, for instance.

I _would_ recommend regardless that you add a test like in t7004's
"signed tag with embedded PGP message" if you apply this to tags as well
as commits.  That requires a special case in our interoperability code
(since it normally converts things that look like signatures, but when
we're _generating_ a tag, we don't want to do that since there are no
signatures yet) and making sure we do the same thing in fast-import will
avoid corruption in our conversions.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA