Разработчики последней ветки имеют пустую папку libtai-mutoso.
Git буквально не может хранить пустую папку, а ваша не делает этого. Случилось так, что кто-то попытался обмануть ваш Git, сохранив пустую папку ... и уловка не удалась.
Есть два связанных приема, оба описаны в Как мне добавить пустой каталог в репозиторий Git? Один из них - использовать специальное пустое дерево ha sh, как описано в этом ответе . Как отмечается в самом ответе, это действительно не работает правильно. Другой - использовать пустой подмодуль , как описано в этом ответе . Этот метод работает (с некоторыми ограничениями).
Похоже, тот, кто создал репозиторий, который вы клонировали и пытаетесь использовать сейчас, попытался использовать трюк с подмодулем, но ошибся .
Уловка с подмодулем использует тот факт, что, когда Git хранит информацию о подмодуле - в так называемом gitlink , который представляет собой объект с mode 160000, который вы видите в сообщение об ошибке - суперпроект Git создаст каталог / папку, а затем - позже, когда вы ему скажете - создайте .git в этом каталоге и клонируйте подмодуль и используйте клон подмодуля для заполнения этого каталога содержимым .
Обратите внимание, что этот новый каталог / папка не пуст в конце: он содержит .git, а затем ваш суперпроект Git запускает git checkout, в некоторых точка, чтобы заполнить папку содержимым какого-то коммита в подмодуле. Но все это произойдет позже, когда вы скажете своему Git сделать это. Если вы никогда не дойдете до того, чтобы сообщить своему Git заполнить мои подмодули , он никогда не дойдет до шага создания .git. 1
информация, необходимая вашему Git, чтобы сказать, какой репозиторий Git ваш суперпроект Git должен клонировать, и фиксация, которую он должен проверить позже, содержится в двух местах суперпроекта:
- имя и URL-адрес для репозитория подмодуля находятся в
.gitmodules, а - фиксация ha sh ID, который суперпроект Git должен
git checkout в подмодуле, это ha sh ID, который вы см. в сообщении об ошибке выше.
ha sh ID должен быть действительным ha sh идентификатором некоторой фиксации, которая действительно существует в этом репозитории подмодулей. Суперпроект Git обычно на самом деле не проверяет , что он действителен - во всяком случае, пока: эта проверка происходит позже. Но есть один особый случай, и вы только что его видели.
В частности, ha sh ID 0000000000000000000000000000000000000000 (40 нулей) в Git зарезервирован и называется null ha sh ID или null sha1 в некоторых местах, включая сообщение об ошибке, которое вы видели:
error: cache entry has null sha1
Запись в кеше может иметь только это null ha sh ID в некоторых особых случаях, и это не один из тех особых случаев.
Правильная информация должна существовать в то время, когда ваш Git выполняет git checkout фиксации суперпроекта , чтобы ваш Git не жаловался, что что-то не так, и отказывался проверять фиксацию. Но в репозитории, который вы клонировали, информация в коммите, который вы пытаетесь проверить, неверна.
Итак, резюмируя проблему: кто-то пытался использовать трюк с подмодулем, но ошибся. Результатом является фиксация, которая ваш Git отказывается проверять.
Как мне теперь переключиться на ветку dev?
Получить кого угодно заставили репозиторий перестать использовать подмодули неправильно.
Ваш (и их) лучший вариант - вообще не пытаться сохранить пустую папку. Это не стоит хлопот. Если они намеревались сохранить настоящий подмодуль - что возможно, - пусть они исправят свой репозиторий, чтобы в нем был правильный подмодуль.
1 Если и когда вы делаете сообщаете своему суперпроекту Git об обновлении подмодулей, если вы использовали уловку с «пустым подмодулем», которая работает, репозиторий, который вы клонируете, имеет в его фиксации нет файлов. В примере этого ответа используется фиксация e84d7b81f0033399e325b8037ed2b801a5c994e0. Таким образом, каталог заканчивается одной записью с именем .git. В современном Git этот .git представляет собой файл, содержащий одну строку. В более старых версиях Git это каталог, содержащий клон репозитория empty-submodule, который содержит одну фиксацию без файлов в нем.