1

I have a super project named Root and a submodule named subB on which I have no write permission. now I want to git a new branch in another machine . but when run "git submodule update", get error :

"fatal: reference is not a tree: b4ec396a0e1da795a5187f7acf90f686c23c6940 Unable to checkout 'b4ec396a0e1da795a5187f7acf90f686c23c6940' in submodule path 'subB'". so I tried all kinds of ways to resolve the issue but I failed. who can answer the following questions for me , thanks:

  1. does the ref 'b4ec396a0e1da795a5187f7acf90f686c23c6940' means local commit in submodule subB? I could see its info only by 'git log b4ec396a0e1da795a5187f7acf90f686c23c6940' in submodule directory 'subB', but in super project I see nothing by the same command.
  2. the ref means a commit in local sumodule repo? because i have no write permission for the remote repo. so I am sure it only on local. buy why the error occurs when I update in another machine. the remote repo should have no idea about the local commit!
  3. how to resolve the issue?
yong
  • 11
  • 2

1 Answers1

0

It probably means that a commit b4ec396 was done in subB, but not pushed in origin/subB (the upstream repo for subB).
However, the parent repo has recorded that gitlink (special entry in the index), and was pushed to origin/Root.

On the other machine, when the parent repo Root is cloned, it cannot checkout subB, because it references a SHA1 which is not present in origin/subB.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • how to get to know what is the gitlink and revert the commit in parent repo? – yong Jul 18 '15 at 13:39
  • @yong the gitlink is `b4ec396`, but since it does not exit, all you can do is `git clone` the `subB` repo in the `subB` folder, then, from `Root` folder, check `git status`: it should say the gitlink has changed (since the `subB` repo would be checked out at a different SHA1) .You can then add and commit that `subB` gitlink from the `Root` folder, and `git push` it. That way, the next `git clone Root` followed by a `git submodule update init` will actually work, since it will ask for an *existing* SHA1 of the `subB` repo. – VonC Jul 18 '15 at 13:42