Git — голое репо не может иметь рабочее дерево для главной ветки — ПОЧЕМУ?

Я работаю над некоторым серверным программным обеспечением, чтобы выполнить слияние. Используя git worktree, можно проверить данную ветку на голое репо и объединить в нее другую ветку. Это очень быстро, даже с большими репозиториями.

Единственным исключением является слияние с master. Когда я делаю git worktree add /tmp/path/to/worktree master, я получаю сообщение об ошибке:

фатальный: «мастер» уже извлечен в «/path/to/bare/repo»

Но это явно не так, git worktree list дает:

/путь/к/голым/репо (голым)

... и, конечно же, по этому пути нет рабочего дерева, только обычные файлы репо, которые вы ожидаете.

ОБНОВЛЕНИЕ: я связался с сопровождающими git, и они согласились, что это может быть ошибка. У меня есть предварительный патч от них для тестирования. Кроме того, мне удалось воспроизвести желаемое поведение без патча.

На данный момент я не совсем уверен, что такое граничное условие или основная причина, и может быть исправление, ожидаемое от git.


git merge version-control git-bare git-worktree
person mtutty    schedule 05.10.2016    source источник
comment
Из чтения документов кажется, что вам может потребоваться передать параметр -b, чтобы создать ветку, чтобы это работало.   -  person Mike Gorski    schedule 06.10.2016
comment
Хм. Но в этом репо есть существующая основная ветка. Сообщение об ошибке, похоже, также подтверждает это. Возможно, это непонятно из моего описания выше, но этот подход отлично работает (без сообщений об ошибках) с другими ветками, включая слияние from master с другой веткой.   -  person mtutty    schedule 06.10.2016

Ответы (2)


arrow_upward
8
arrow_downward

Оказывается, это ошибка в git, начиная с реализации рабочего дерева в 2.5 и выше.

Голый репозиторий все еще имеет рефссылку HEAD. Все, на что указывает эта ссылка, рассматривается git (до версии 2.10 включительно) как ветка по умолчанию для новых клонеров и (ошибочно) обрабатывается так, как будто она находится в активном рабочем дереве.

Я получил патч от сопровождающих git, чтобы исправить это поведение, и, похоже, он работает. В качестве альтернативы должна быть возможность использовать update-ref в голом репо для временного переключения с мастера.

Я буду тестировать оба этих варианта.

person mtutty    schedule 10.10.2016

arrow_upward
3
arrow_downward

Я думаю, что это неправильно. Вы можете сообщить об этом им. Обсуждений пока не нашел, хотя случай кажется очевидным.

В качестве обходного пути вы можете запустить git update-ref --no-deref HEAD 'HEAD^{commit}' . Он отсоединяет текущий HEAD, так что мастер становится не проверенным

person max630    schedule 07.10.2016