Почему репо Google синхронизируется в безголовое состояние - PullRequest
0 голосов
/ 04 мая 2018

Таким образом, в manifest.xml вы указываете ревизию для проекта, например, мастер ревизий для проекта foo. Тогда вы

repo sync

и загружает основную ветку проекта foo. Но это на самом деле не проверить эту ветку. Скорее, это ставит вас в безголовое состояние, как-то начиная с мастера ...? Это кажется довольно громоздким, если я собираюсь РАБОТАТЬ с синхронизированным проектом.

Я знаю, что это можно довольно легко "исправить", но, поскольку это кажется настолько нелогичным, я предполагаю, что у них была довольно веская причина для того, чтобы перевести вас в обезглавленное состояние по умолчанию. Я хотел бы понять предполагаемый рабочий процесс, прежде чем отклониться от него, поэтому кто-нибудь может объяснить это?

1 Ответ

0 голосов
/ 05 мая 2018

«Безголовое состояние» в Git называется detached HEAD.

В манифесте (например, .repo/manifest.xml) мы видим, что каждый проект имеет revision. Это может быть коммит (40a264de45eb035c67aa32d73c767ed7d9378ba2), тег (refs/tags/v1.0), ветвь (refs/heads/master или master) или любой допустимый git ref (refs/changes/11/22211/1).

repo sync клонирует голые репо в $coderoot/.repo/projects/ и $coderoot/.repo/project-objects, вызывает git rev-parse в голых репо, чтобы получить коммит revision, а затем git checkout этот коммит в репо под $coderoot/, что всегда приводит к отделенной ГОЛОВЕ. См. project.py .

Обратите внимание, что две команды вызываются в двух репозиториях. Предположим, что есть ветвь master в $coderoot/.repo/project/foo.git и ветвь master в $coderoot/foo/. Два masters могут указывать на разные коммиты и помнить, что разрешено запускать repo sync в существующем каталоге. git checkout master in $coderoot/foo/ извлечет неправильный код. Названия веток не заслуживают доверия, а коммиты. Вот почему repo sync всегда проверяет фиксацию вместо ветки.

...