#git #github #bitbucket #git-branch #git-submodules
#мерзавец #github #битбакет #git-ветвь #git-подмодули
Вопрос:
Я работаю над проектом, имеющим один подмодуль git (… и я абсолютно не знаком с этим!), и я не понимаю, почему он не получает последнюю версию проверенной ветви!!!
Позвольте мне более подробно описать, чем я занимаюсь…
Мой .gitmodules похож на этот:
[submodule "MySubmodule"] path = MySubmodule url = ../my-sub-repo.git branch = master Теперь я хочу сменить ветку, больше не использовать master , а «другое».
После клонирования моего «основного» репозитория git я сначала изменяю свой .gitmodules на
[submodule "MySubmodule"] path = MySubmodule url = ../my-sub-repo.git branch = other Затем я инициализирую свой подмодуль, выполнив следующую команду:
git submodule update --init --recursive Я получаю следующий результат:
Submodule 'MySubmodule' (ssh://git@xxx.xxx.xxx:7999/project/my-sub-repo.git) registered for path 'MySubmodule' Cloning into '/tmp/project/my-main-repo/MySubmodule'... Submodule path 'MySubmodule': checked out '499ae4ccb7bf59c2c3acab5b63e1e6ff58b49ca4' Что меня здесь раздражает, так это пересмотр: 499ae4ccb7bf59c2c3acab5b63e1e6ff58b49ca4 !!! Он не последний в моей ветке other в моем репозитории my-sub-repo
Если в моем .gitmodules я изменю branch на:
branch = other@HEAD Я получаю тот же результат: не последний коммит!!!
Я нашел обходной путь для этой странной ситуации: если после git submodule update --init --recursive того, как я запущу:
git submodule update --remote Submodule path 'MySubmodule': checked out '29ffbebe032badb8728729c7ab30e96e41fc0a84' Теперь ожидаемая редакция проверена!!!
Что мне нужно понять, так это почему я не получаю последнюю версию other ветви, когда она только запущена git submodule update --init --recursive ? Что заставляет git принять решение использовать ревизию 499ae4ccb7bf59c2c3acab5b63e1e6ff58b49ca4 ?
Спасибо за помощь
С наилучшими пожеланиями, Фил
Комментарии:
1. Вот как должны работать подмодули. (Людям это не нравится, но так они должны работать.) Идентификатор хэша, используемый в подмодуле, записывается в коммитах суперпроекта. Название филиала, если у вас есть один набор, действительно подходит для этого
update --remoteварианта. Обратите внимание, что после использования этой опции для обновления подмодуля вам следует создать и протестировать суперпроект, затем добавить каждый подмодуль (для записи нового идентификатора хэша) и зафиксировать в суперпроекте (чтобы записать, что вы заявляете, что все это работает, и это то, что следует проверить в будущем).2. Я не уверен , что понимаю «Идентификатор хэша, используемый в подмодуле, записан в коммитах суперпроекта»: Когда я изменяю ветвь с
masterнаother, ничего не должно быть «записано в суперпроекте», возвращающем эту новую ветвь: какова логика этого?3. Кто сказал что-нибудь о логике? 🙂 Более серьезно: когда вы делаете фиксацию в обычном репозитории без подмодулей, фиксация записывает каждый файл, который следует использовать . Та же идея применима даже в том случае, если у вас есть подмодуль: подмодуль S в настоящее время проверен по хэшу фиксации H. Имена ветвей указывают на разные идентификаторы хэша в разное время, но хэш H навсегда будет означать именно эти файлы . Таким образом, суперпроект записывает хэш H вместе со всеми файлами суперпроекта. Позже, проверив, что фиксация в суперпроекте извлечет фиксацию H в подмодуле, и все файлы будут правильными.