1

I have a long running issue that differs from other similar posts on this error. Googling or searching SO gives many cases where this error's caused by the referenced commit not being accessible in the repo- that isn't the case here.

I have a GUI repo and a DLL repo. The GUI has a submodule pointing to a specific commit of the DLL. The two repos are worked on separately and, when needed, the GUI's submodule is updated to the latest stable DLL by going into the submodule folder and executing the command

git checkout [commit ID]

Most of the time when this is done on a GUI folder in which there's been active development the command fails with the "not a tree" error. Cloning the GUI folder afresh and repeating the steps works, and is the way I've been working around this. It's inefficient though, and for an upcoming project where there are going to be multiple submodules frequently updated it'll become a problem, so I've gone back and tried to figure out what's going on.

When I have a GUI that won't let me update the submodule (but has no changes waiting to be committed,) doing a git reset either from the commandline or from the Git Extensions GUI, or a 'pull/fetch' from GitExt, has no effect on the error and doing a diff between the work folder and a clean clone shows lots of changes remain between the two- generated .obj and .exe files for instance.

If I then do "Clean working directory" then many files are removed, mostly ones that are in .gitignore (so that isn't causing stuff to be left behind and blocking things.) The only changes then between work and clean folders are in the .git folder, yet the error still arises.

If I take a clean folder and do a build and then try updating the submodule then there's no problem, even when I don't delete the files that build process creates, some of which are below the submodule's folder. The issue seems to arise when a folder's been worked on for a while and has a few commits, but I've not yet found a definite trigger.

Does anyone know what may be going on and how to fix without starting with a clean clone of the repo?

Edit to add details relating to the comments; I've seen the referenced post. A lot of it relates to cases where the submodule is pointing to a hash that's not present in the repo for whatever reason, which clearly isn't the case here. To cover the rest;

Deleting the submodule folder, going up to the top, typing "git submodule update -init" then going back into the submodule folder and trying to checkout the new module again doesn't help.

Doing 'git submodule sync' then 'got submodule update' doesn't help

Binary version problem? I was on Git 2.40.1. Updated to 2.41.1. Doesn't help.

There's a suggestion to remove and re-add the submodule. It involves manually editing config files and is a more cumbersome approach than re-cloning the repo.

Craig Graham
  • 1,161
  • 11
  • 35
  • Afaik the paradigm is: you will always use the `main` (`master`) branch of the submodule in the repository using the submodule. And then you will update the submodule in the GUI repository like this: `git pull --recurse-submodules`. So your mistake is going in the submodule folder and doing the checkout. Not the root cause of the problem necessarily but wrong in general. Have you read about that error in general and do you understand it? It sounds like git doesn't know about that commit you're trying to checkout to. – Eljas Hyyrynen Jul 11 '23 at 13:22
  • Thanks. Yes, the commit being missing from the repo is the main cause, but clearly not the case here because it's fine when I pull down a clean clone of the GUI and update the submodule in there. The submodule can't be to a commit on the master branch of the DLL because different versions of the DLL have their own branches, and if there's a bugfix to a release then it's that commit on that release branch that needs to be the submodule. The checkout I mentioned is to update the submodule and specify the specific hash of the commit the submodule should be. – Craig Graham Jul 12 '23 at 07:51
  • Have you googled `reference is not a tree`? Have you read all the answers on [this](https://stackoverflow.com/questions/2155887/git-submodule-head-reference-is-not-a-tree-error) SO post? Have you done `git fetch` and `git submodule foreach git fetch` to update your refs? – Eljas Hyyrynen Jul 12 '23 at 09:54
  • 1
    Huh. `git fetch` from the terminal fixes it. I was doing a fetch from the GitExt GUI (after making sure the commit I want has been pushed) which has always seemed to be doing what I expect but there's clearly some difference when doing it in the terminal. Thanks. This has wasted a lot of time over the past few months. – Craig Graham Jul 12 '23 at 12:22
  • I will post an answer for this so we can "close" the issue and you can accept the solution. I hope it helps someone else, too. – Eljas Hyyrynen Jul 12 '23 at 13:00

1 Answers1

0

From terminal:

git fetch

and if needed,

git submodule foreach git fetch

will solve the problem.

Please read more on why the error occurs here. tldr; git fetch updates the refs and thus fixes your root cause.

Eljas Hyyrynen
  • 233
  • 1
  • 11