Почему обновление подмодуля git завершается с ошибкой «fatal: remote error: upload-pack: not our ref»? - PullRequest
0 голосов
/ 11 апреля 2020

У меня репо git с несколькими подмодулями. Я попытался удалить и добавить рассматриваемый подмодуль ( scopatz's nanor c), однако ошибка сохраняется при удалении и повторном добавлении. Когда я клонирую репо в новое место, я автоматически обновляю его на git submodule update --init --recursive, то есть когда это не удается, но только для этого подмодуля ... Ниже приведен соответствующий вывод команды с GIT_TRACE=2:

23:01:26.918691 run-command.c:1569      run_processes_parallel: preparing to run up to 1 tasks
23:01:26.933567 run-command.c:1601      run_processes_parallel: done
23:01:26.934373 run-command.c:646       trace: run_command: git gc --auto
23:01:26.966805 git.c:344               trace: built-in: git gc --auto
23:01:26.991059 git.c:344               trace: built-in: git rev-parse --local-env-vars
23:01:27.015684 git.c:344               trace: built-in: git rev-parse --local-env-vars
23:01:27.032282 git.c:344               trace: built-in: git symbolic-ref -q HEAD
23:01:27.053948 git.c:344               trace: built-in: git config --get branch.master.remote
23:01:27.073636 git.c:344               trace: built-in: git fetch origin 151d94a8754b0a612315fc191c5373cc0055c13d
23:01:27.079657 run-command.c:646       trace: run_command: git-remote-https origin https://github.com/scopatz/nanorc.git
23:01:28.441725 run-command.c:646       trace: run_command: git rev-list --objects --stdin --not --all --quiet
23:01:28.452267 run-command.c:646       trace: run_command: git fetch-pack --stateless-rpc --stdin --lock-pack --thin https://github.com/scopatz/nanorc.git/
23:01:28.467757 git.c:344               trace: built-in: git fetch-pack --stateless-rpc --stdin --lock-pack --thin https://github.com/scopatz/nanorc.git/
fatal: remote error: upload-pack: not our ref 151d94a8754b0a612315fc191c5373cc0055c13d
fatal: The remote end hung up unexpectedly
Fetched in submodule path 'submodules/nano', but it did not contain 151d94a8754b0a612315fc191c5373cc0055c13d. Direct fetching of that commit failed.

надеясь, что кто-то здесь может помочь, я в основном заблудился на этом этапе.

=== РЕДАКТИРОВАТЬ: Решение Шаги ниже ===

cd {submodule path}
git reset --hard origin/master
cd -
git clean -n
git add {submodule path}
git commit
git submodule update --init --recursive

Без ошибок, круто.

1 Ответ

0 голосов
/ 11 апреля 2020

С Git и подмодулями вы начинаете как минимум с двух Git репозиториев. Одним из них является «ваш» репозиторий - основной, который Git будет называть суперпроектом . Второй Git репозиторий - это какой-то другой Git репозиторий: в этом нет ничего особенного. Просто в вашем суперпроекте есть эти две части:

  • Инструкции по клонированию подмодуля. Это позволяет вашему Git запускать git clone при необходимости, например, в течение git submodule update --init.

  • Необработанный ha sh ID некоторого коммита, который должен быть в этот другой Git репозиторий. Ваш основной репозиторий после клонирования или запуска git fetch, если это необходимо, в вашем клоне другого репозитория Git, запустит git checkout <em>hash</em>, используя этот необработанный га sh ID.

Ваш суперпроект запрашивает ha sh ID 151d94a8754b0a612315fc191c5373cc0055c13d в репозитории Git, который можно клонировать из https://github.com/scopatz/nanorc.git. Этот коммит просто не существует в этом репозитории, поэтому он не находится ни в одном клоне, который вы делаете.

Знаете ли вы, почему ваш суперпроект перечисляет этот коммит с идентификатором sh, даже если он не существует? (Я конечно не знаю.) Вы не можете получить это от их Git, потому что у них его нет. Это то, что все эти сообщения об ошибках говорят вам.

Вы можете попробовать поискать в других репозиториях (или Google) 151d94a8754b0a612315fc191c5373cc0055c13d (я только что попробовал с Google, но они не могут его найти). Или, если вас не особо интересует этот коммит, попробуйте сказать своему Git - вашему суперпроекту - что он должен получить другой коммит, тот, который делает существует, и поэтому вы можете получить.

Какой коммит должен получить? Понятия не имею: это решать вам. Обратите внимание, что место , где вашего суперпроекта перечисляет необработанный коммит ha sh из подмодуля: в каждом коммите. Вы можете git checkout сделать коммит, возможно, кончик какой-то ветки, в своем суперпроекте. Затем вы можете войти в подмодуль, выбрать коммит, который вам нравится, использовать git checkout в этом подмодуле - в конце концов, это еще один клон Git, так что вы можете выполнить там любую команду Git - чтобы проверить нужный коммит. Затем выйдите из субмодуля (измените каталоги обратно на ваш суперпроект) и запустите git add в пути субмодуля и git commit, чтобы записать новый желаемый идентификатор ha sh. Этот новый коммит теперь запрашивает , что конкретный га sh ID.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...