Answers: <p>You might have to create a script to automate changing the ID's is the only answer I can think of.</p>
  <p>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 &amp; pointing to the previous repo.</p>
  <p>But at least a relatively small script could achieve this though.</p>
  
Answers: CC BY-SA 4.0
Answers: 2024-02-26T23:16:18.467Z
Answers: Thank you both - I would be happy to script this, but I have no idea how to do so; GitHub issues are not (as far as I know) tracked using Git, and the timeline inside a GitHub issue is automatically created by GitHub's software and there doesn't seem to be an API for modifying it. If you know of a way to do it via scripting, that would be great.
Answers: user533676
Answers: CC BY-SA 4.0
Answers: 2024-02-17T23:07:06.657Z
Answers: 2024-02-18T06:36:17.717Z
Answers: 2024-02-18T06:36:17.717Z
Answers: Definity
Body: <p>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:</p>
  <ol>
  <li>Use something similar to the method outlined at <a href="https://blog.jdriven.com/2021/04/how-to-merge-multiple-git-repositories/" rel="nofollow noreferrer">https://blog.jdriven.com/2021/04/how-to-merge-multiple-git-repositories/</a> to merge repositories into the target monorepo</li>
  <li>Use the GitHub CLI <code>gh issue transfer</code> tool to transfer the issues from the source repos to the target monorepo</li>
  </ol>
  <p>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:</p>
  <ul>
  <li>Let's say I have a bug which is documented in GitHub issue #123 in repository <code>RepoA</code></li>
  <li>Let's say I make commit <code>abcd123</code> in repository <code>RepoA</code> which fixes the bug, and in the commit message I put something like &quot;Closes #123&quot;</li>
  <li>In the GitHub issue #123 in <code>RepoA</code>, I will now see a message in the timeline along the lines of &quot;UserABC closed this as completed in abcd123 yesterday&quot;, and the &quot;abcd123&quot; will be a link to the commit in question. My action will also close the issue because I used the keyword &quot;Closes&quot;.</li>
  <li>At some point in the future, I merge <code>RepoA</code> into my <code>monorepo</code> repository (also hosted on GitHub under the same organization) and transfer its issues into the <code>monorepo</code> using the techniques described in (1) and (2) above. The method I use to merge preserves commit IDs, so now I have commit ID <code>abcd123</code> in the <code>monorepo</code> as well, and will have the GitHub issue (though with a different ID) in <code>monorepo</code> too.</li>
  <li>The message in the timeline in the transferred issue in the <code>monorepo</code> which previously said &quot;UserABC closed this as completed in abcd123 yesterday&quot; has changed, however: it now explicitly points to the original repository and says &quot;UserABC closed this as completed in RepoA@abcd123 yesterday&quot;, and the link is to the original commit in <code>RepoA</code>, not the identical commit in the new <code>monorepo</code>.</li>
  </ul>
  <p>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 <code>monorepo</code> migration is correct and complete. When you do this (we tried it on a couple of test repos) the message changes to &quot;UserABC closed this as completed yesterday&quot;, 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 <code>monorepo</code>.</p>
  <p>Is there a way to update/edit these GitHub issues so they point to the migrated/merged commit in the <code>monorepo</code>, instead of to the original commit in the source repository? Or some other way to solve this conundrum?</p>
  
Tags: <git><github><migration>
Title: How to update GitHub issue commit links after migrating code and issues from another repository?
UserDisplayName: user533676
ThreadText: # How to update GitHub issue commit links after migrating code and issues from another repository?
  
  (Asked by: username_0 on 2024-02-09)
  
  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?
  
  **Tags:** git, github, migration
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2024-02-17. Score: 0
  
  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.
  
  > **Comments:**
  > **username_0**: Thank you both - I would be happy to script this, but I have no idea how to do so; GitHub issues are not (as far as I know) tracked using Git, and the timeline inside a GitHub issue is automatically created by GitHub's software and there doesn't seem to be an API for modifying it. If you know of a way to do it via scripting, that would be great.  
  
  ---
  
  