2016-10-05 5 views
11

Я работаю над некоторым программным обеспечением на стороне сервера, чтобы выполнить слияние. Используя git worktree, вы можете проверить данную ветку для голого репо и слить в нее другую ветку. Это очень быстро, даже с большими репозиториями.Git - Bare repo не может иметь worktree для главной ветки - ПОЧЕМУ?

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

fatal: 'master' is already checked out at '/path/to/bare/repo'

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

/path/to/bare/repo (bare)

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

UPDATE: Я связался с сопровождающими git, и они согласны с тем, что это может быть ошибка. У меня есть предварительный патч от них, чтобы проверить. Кроме того, я также смог воспроизвести желаемое поведение без патча.

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

+0

Из чтения документов вам, возможно, потребуется передать опцию '-b', чтобы создать ветку для ее работы. –

+0

Hm. Но в этом репо есть существующая мастер-ветвь. Сообщение об ошибке, похоже, также подтвердит это. Возможно, это не ясно из моего описания выше, но этот подход работает отлично (без сообщений об ошибках) с другими ветвями, включая слияние * от * master до другой ветки. – mtutty

ответ

6

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

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

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

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

3

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

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