0

So here's what you need to know:

  • Repo A was a large legacy repo used in several other projects as a submodule on GitHub Enterprise.
  • While migrating Repo A to GitLab, we found that some commits deep in the history had their data corrupted and were causing the migration to fail.
  • In order to remove these corrupted files, we had to rewrite the git history around the corrupted commit.
  • Repo B uses Repo A as a submodule.

I have been attempting to update Repo B by doing the following:

  1. Clone Repo B from GitLab
  2. Update the path in .gitmodules to point to the new (GitLab) location of Repo A
  3. git submodule init
  4. Confirm that Repo A's url is correct and pointing to the new (GitLab) Repo A
  5. cd repo-b/repo-a
  6. git checkout $hash where $hash is the exact same commit in Repo A that we used to point to, but with the new hash because history was rewritten.

I keep getting this error:

fatal: reference is not a tree: 01b517847508dd5942887950e4a5ab1468bb21b4

I can't figure out what I'm doing wrong, every answer I've seen seems to imply that I should be able to checkout a specific hash in the submodule and then commit that change to the repo.

Also, just for clarification, I did confirm that my hash is correct and exists by checking it out in the new (GitLab) Repo A, so it's there.

C. Cannon
  • 39
  • 1
  • 6
  • Make sure that when you check out commits in repo B (the one that uses A as a submodule) you are *not* using "recursive" checkout. That is, you want to get the commit from the superproject, with its wrong submodule hash ID. You can then use this commit to build a new *superproject* commit in which the hash ID is updated in place. Basically, you must now rewrite repository B so that it uses the new hash IDs for each gitlink (for which you need the map of "old A commit to new A commit" from the conversion of A). – torek May 27 '22 at 21:24
  • Once you've built a new B superproject repo, *then* recursive checkout from the new rebuilt B should work. Until then you're stuck with labor-intensive manual non-recursive superproject checkouts followed by careful submodule checkouts by hash ID done "by hand". – torek May 27 '22 at 21:25
  • It does sound like you're in this process, so I think maybe what's going wrong is that B has already cloned the "wrong" A instead of the "right" A and is now stubbornly using the old A. – torek May 27 '22 at 21:27

1 Answers1

0

I found a solution! I can't explain why it works, but it fix the error.

I had previously tried this with a git submodule update between step 3 and step 5, and that didn't seem to work. However:

git submodule init
git submodule update --checkout

Did in fact allow the hash checkout to succeed in the submodule.

C. Cannon
  • 39
  • 1
  • 6