How to update GitHub issue commit links after migrating code and issues from another repository?

Question

We are an organization with multiple repositories in GitHub which we are merging into a monorepo. We have no issues with the mechanics of how to do this:

1. Use something similar to the method outlined at https://blog.jdriven.com/2021/04/how-to-merge-multiple-git-repositories/ to merge repositories into the target monorepo
2. Use the GitHub CLI gh issue transfer tool to transfer the issues from the source repos to the target monorepo

The problem is that we make heavy use of issue IDs in our Git commit messages in order to link issues in GitHub to specific commits, and those links still refer to the commit in the original repository after we transfer them. An example will illustrate the problem:

• Let's say I have a bug which is documented in GitHub issue #123 in repository RepoA
• Let's say I make commit abcd123 in repository RepoA which fixes the bug, and in the commit message I put something like "Closes #123"
• In the GitHub issue #123 in RepoA, I will now see a message in the timeline along the lines of "UserABC closed this as completed in abcd123 yesterday", and the "abcd123" will be a link to the commit in question. My action will also close the issue because I used the keyword "Closes".
• At some point in the future, I merge RepoA into my monorepo repository (also hosted on GitHub under the same organization) and transfer its issues into the monorepo using the techniques described in (1) and (2) above. The method I use to merge preserves commit IDs, so now I have commit ID abcd123 in the monorepo as well, and will have the GitHub issue (though with a different ID) in monorepo too.
• The message in the timeline in the transferred issue in the monorepo which previously said "UserABC closed this as completed in abcd123 yesterday" has changed, however: it now explicitly points to the original repository and says "UserABC closed this as completed in RepoA@abcd123 yesterday", and the link is to the original commit in RepoA, not the identical commit in the new monorepo.

I understand why this happens, and it's arguably even correct behavior, but it's undesirable for us because one of our goals is to ultimately delete the original repositories completely once we know the monorepo migration is correct and complete. When you do this (we tried it on a couple of test repos) the message changes to "UserABC closed this as completed yesterday", with no commit ID, so we would lose this useful linkage between issues and commits, and even if we don't delete the source repositories the links are less useful because they take you outside of the monorepo.

Is there a way to update/edit these GitHub issues so they point to the migrated/merged commit in the monorepo, instead of to the original commit in the source repository? Or some other way to solve this conundrum?

Answer 1

You might have to create a script to automate changing the ID's is the only answer I can think of.

Unfortunately Git isn't designed to be used like this. It's version tracking software so it tracks all changes including the previous repos commits & pointing to the previous repo.

But at least a relatively small script could achieve this though.