Можно ли закончить git detached head от pull, push, fetch или rebase?

У меня есть серверное приложение Python, которое обрабатывает репозиторий git. Он создает коммиты и переключает ветки для локального применения изменений, а затем отправляет их в удаленное репо.

По какой-то причине пользователи, запускающие сервер на Mac, видят, что их репозиторий оказывается в состоянии detached HEAD. Это никогда не случалось с пользователями, запускающими сервер на машинах Windows.

Инструмент использует GitPython, и нет службы, которая выполняет проверку для определенного SHA фиксации, он только переключается на имена ветвей. Он выполняет git pull --rebase и git push.

Есть ли способ оказаться в состоянии detached HEAD, выполнив вытягивание с перебазированием, выборкой или отправкой, или любым другим способом, который не является проверкой для фиксации SHA?


git macos windows python-2.7 gitpython
person Haibrayn González    schedule 02.10.2020    source источник
comment
Если вы извлекаете ветку renote или тег, вы попадаете в состояние detached HEAD, просто чтобы назвать 2, которые не имеют дело с идентификаторами ревизий.   -  person eftshift0    schedule 02.10.2020
comment
вытягивание суперпроекта, скорее всего, поместит вложенные репозитории в отдельную голову. Ответ на ваш вопрос - да.   -  person Daemon Painter    schedule 11.01.2021

Ответы (2)


arrow_upward
1
arrow_downward

При неполной перебазировке, которая, как правило, останавливается из-за конфликта слияния, хотя любая ошибка, например проблема с правами доступа, также приведет к тому, что вы останетесь в середине перебазирования. Сам Rebase использует режим detached-HEAD, поэтому здесь у вас будет отдельный HEAD. Это наиболее вероятный источник проблемы.

(Как eftshift0, отмеченный в комментарии, передача имени тега в git checkout или любого имени, не являющегося именем ветки, также приводит к отключению HEAD.)

person torek    schedule 02.10.2020
comment
Под ошибкой вы подразумеваете конфликт слияния? Есть ли способ воспроизвести это, чтобы провести тест и убедиться, что проблема решена? - person Haibrayn González; 02.10.2020
comment
Ошибка была неправильным термином (я изменю его), но конфликта слияния было бы достаточно, да. Достаточно всего, что останавливает перебазирование. Фактическая ошибка также сделала бы это, но это довольно редко. - person torek; 02.10.2020
comment
Чтобы воспроизвести его, создайте ситуацию, в которой ваш rebase столкнется с конфликтом слияния. Например, пусть репозиторий содержит свою собственную единственную фиксацию с отличием в строке N некоторого фиктивного файла, затем внесите другое однострочное изменение в строку N в вышестоящем репозитории в вышестоящей ветке, которую будет использовать нижестоящий репозиторий (независимо от того, восходящая ветвь, которая может быть). - person torek; 02.10.2020
comment
Интересно. Есть ли какие-либо идеи о том, что может пойти не так в Mac, что не пойдет не так в Windows? - person Haibrayn González; 10.10.2020
comment
macOS (во всяком случае, на HFS и подобных) использует NFD или NFC (я не могу вспомнить, какой) для имен файлов. Это влияет на такие имена, как agréable: одна форма имеет ударение и e как отдельные символы, а другая имеет ударение-e как один символ. Поэтому, если у вас есть репозиторий, который использует обе формы в своем имени UTF-8, macOS не может сохранить это в вашем рабочем дереве (что создает всевозможные проблемы). Я не уверен в Windows. - person torek; 10.10.2020
comment
Когда возникают конфликты перебазирования, инструмент решает их, извлекая конфликтный файл из последней фиксации и продолжая перебазирование, например git checkout <latest commit> -- path/to/file. Вы думаете, что это может вести себя по-другому в Mac? - person Haibrayn González; 10.10.2020
comment
Это должно быть в основном одинаково для macOS и Windows. - person torek; 11.10.2020

arrow_upward
1
arrow_downward

Похоже, ошибка была вызвана тем, что git-lfs не установлен по умолчанию в macOS с рабочих машин. Плагин каким-то образом дал сбой и завершился в состоянии detached HEAD.

person Haibrayn González    schedule 11.01.2021