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:
- 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
- Use the GitHub CLI
gh issue transfertool 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
- Let's say I make commit
RepoAwhich 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
monoreporepository (also hosted on GitHub under the same organization) and transfer its issues into the
monorepousing the techniques described in (1) and (2) above. The method I use to merge preserves commit IDs, so now I have commit ID
monorepoas well, and will have the GitHub issue (though with a different ID) in
- The message in the timeline in the transferred issue in the
monorepowhich 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
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
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?