修复分裂错误的 git 子树

Question

I have a git repo with a subtree that was set up years ago with a bad split commit that's throwing errors when I try to do a git subtree push . The error I get looks something like this:

git push using:  <remote>
fatal: ambiguous argument '<sha>^{commit}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
could not rev-parse split hash <sha> from commit <sha>

When I look at the commit the error is complaining about, it's referring to:

• a git-subtree-dir which is the name of the git prefix (fine)
• a git-subtree-split which refers to a hash that isn't there anymore( not fine).

I can assume that the initial split was made on a branch that was never merged back, and that any subsequent subtree pulls/pushes were done on another branch. That commit is gone.

The behavior of git-subtree when doing a push changes depending on git version:

• When I ran it with git 1.8, it would throw an error and delete the branch you're trying to push into on the remote repo(.).
• When running a somewhat later version (I don't know exactly which since I recently upgraded it), it would throw an error and work anyway. It would, however, take a very long time to run since it would go through the entire git repo history.
• When running the latest git version, it just throws the error and refuses to push.

I tried running another split hoping to create another split and fix the issue:

git subtree split --prefix=<prefix> --rejoin --ignore-joins

It created the new split, but I still get the same error when I try to do a subtree push. It looks like the subtree command is still looking at the old split, and throwing an error.

I'm running out of ideas, and I can't git subtree push anymore at all with the latest version of git. The only thing that comes to mind is to change the commit message from the old broken split, but it was made in 2018 and I don't think rebasing from a commit that old is a good idea.

Answer 1

• a git-subtree-split which refers to a hash that isn't there anymore(not fine).

Is it possible that this hash refers to a tag in the subtree repository that would have been git subtree pull ed? That would be the case if that subtree pull happened on an older version of Git (older than 2.32.0)

If so, you could try fetching that hash directly:

git fetch <subtree-repo> <hash>

and then retry your git subtree push .

Git 2.39 and later would suggest that course of action, see https://github.com/gitgitgadget/git/commit/a23e0b69e2d25a893e187d86719de0b12b324579 and more precisely https://github.com/gitgitgadget/git/commit/1762382ab19dd6d5d84dd32e35e25c2b55b651f0 .