Что это за сообщение Git при нажатии на изменения в удаленном репозитории?

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

warning: updating the current branch
warning: Updating the currently checked out branch may cause confusion,
warning: as the index and work tree do not reflect changes that are in HEAD.
warning: As a result, you may see the changes you just pushed into it
warning: reverted when you run 'git diff' over there, and you may want
warning: to run 'git reset --hard' before starting to work to recover.
warning: 
warning: You can set 'receive.denyCurrentBranch' configuration variable to
warning: 'refuse' in the remote repository to forbid pushing into its
warning: current branch.
warning: To allow pushing into the current branch, you can set it to 'ignore';
warning: but this is not recommended unless you arranged to update its work
warning: tree to match what you pushed in some other way.
warning: 
warning: To squelch this message, you can set it to 'warn'.
warning: 
warning: Note that the default will change in a future version of git
warning: to refuse updating the current branch unless you have the
warning: configuration variable set to either 'ignore' or 'warn'.   

Ответ 1

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

Это очень запутанно, потому что теперь он думает, что он проверил последнюю версию ветки, когда на самом деле вы только что обновили ветвь до более новой версии. Итак, когда он теперь выполняет git commit, его фиксация будет по существу возвращать все сделанные вами коммиты. И когда он побежит git diff, он увидит противоположное всему, что вы только что нажали, хотя он, возможно, даже ничего не изменил.

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

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

Ответ 2

С Git 2.3.0 (после февраля 2015 года)

Если в этом удаленном репозитории non-bare никто не работает, то должна быть возможность перейти в извлеченную ветку.

Но чтобы быть более безопасным в этой операции, вы теперь можете (с Git 2.3.0, февраль 2015 г.) сделать в этом удаленном репо:

git config receive.denyCurrentBranch updateInstead

Это более безопасно, чем конфигурация receive.denyCurrentBranch=ignore: оно разрешит толчок, только если вы не отменяете изменение в процессе.

Смотрите коммит 1404bcb Йоханнеса Шинделина (dscho):

receive-pack: добавить еще одну опцию для receive.denyCurrentBranch

При синхронизации между рабочими каталогами может быть удобно обновить текущую ветвь с помощью "push", а не "pull", например, при загрузке исправления изнутри виртуальной машины или при установке исправления, сделанного на пользовательском компьютере (где разработчик не вправе устанавливать демон ssh, не говоря уже о том, чтобы знать пароль пользователя).

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

Новая опция:

updateInstead

Обновите рабочее дерево соответствующим образом, но откажитесь сделать это, если есть какие-либо незафиксированные изменения.


commit 4d7a5ce добавляет дополнительные тесты и упоминает:

В предыдущем тесте тестировался только тот случай, когда путь, подлежащий обновлению с помощью push-to-deploy, имеет несовместимое изменение в целевом рабочем дереве, которое уже было добавлено в индекс, но сама функция хочет, чтобы рабочее дерево было намного чище, чем то, что тестируется.

Добавьте еще несколько тестов, чтобы защитить функцию от будущих изменений, которые ошибочно (с точки зрения изобретателя функции) ослабляют требование чистоты, а именно:

  • Изменение только в рабочем дереве, но не в индексе, все еще должно быть защищено;
  • Не отслеживаемый файл в рабочем дереве, который будет перезаписан при развертывании push-to-deploy, должен быть защищен;
  • Изменение, которое делает файл идентичным перемещаемому файлу, все еще является изменением, которое необходимо защитить (т.е. требование к чистоте функции более строгое, чем к оформлению заказа).

Кроме того, проверьте, что изменение только статистики в рабочем дереве не является причиной для отклонения push-to-deploy.

С Git & lt; 2.3.0 (до февраля 2015 г.)

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

Ответ 3

Это та же проблема, что и Этот вопрос, решение заключается в использовании git init --bare или git clone --bare.