Как Git определяет «пульт, с которого я обычно беру», чтобы определить поведение pu sh .default = simple?

Question

Начиная с Git версии 2.0, значение по умолчанию для параметра конфигурации push.default, если оно не указано в конфигурации пользователя, равно simple.

Согласно документации это означает:

в централизованном рабочем процессе, работайте как восходящий поток с дополнительной безопасностью, чтобы отказаться от pu sh, если имя восходящей ветки отличается от локального.

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

Играя с крайними случаями «git pu sh» при написании учебных материалов, я обнаружил удивительное разветвление вариантов конфигурации:

Если вы находитесь в ветке, для которой не настроен восходящий поток, и вы запускаете git push my-remote, когда у вас есть два пульта дистанционного управления, в некоторых случаях вы получите сообщение об ошибке:

fatal: The current branch my-branch has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream my-remote my-branch

И в В других случаях pu sh завершится успешно и создаст новую ветвь на удаленном компьютере, а ветвь удаленного отслеживания - на go вместе с ним (но не настроит удаленную ветвь как восходящую).

После некоторой путаницы в отношении несоответствия и некоторого покопания в документации я наконец понял, что параметр конфигурации upstream для push.default (который simple иногда действует как ) будет только pu sh для ветвь восходящего потока , и поэтому не удастся, если исходящий поток не настроен, тогда как опция конфигурации current (которая simple также иногда действует как) будет работают независимо от того, настроен ли восходящий поток или нет.

Таким образом, суть вопроса заключается в том, работает ли Git как current или как upstream для определенного пу sh, когда Параметр simple выбран (или оставлен пустым). В документации только сказано, что он работает как current «при отправке на удаленный компьютер, отличный от того, с которого вы обычно получаете». Итак, как он это определяет?

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

Но этот вопрос не о моих особенностях c репо или почему они ведут себя непоследовательно; это всего лишь попытка реконструировать ответ на этот вопрос, который, похоже, неясен в документации.

Мы будем очень признательны за ответы, относящиеся к документации (я не уверен, что там можно найти ответ) ; ответы, относящиеся к исходному коду Git, тоже хороши, но я не совсем бегло читаю C, поэтому объяснение было бы полезным. :)

Answer 1

Вы можете увидеть в t5528-push-default.sh все протестированные варианты использования с git push, используя pu sh policy 'simple'

В частности:

test_expect_success 'push to existing branch, with no upstream configured' '
    test_config branch.master.remote repo1 &&
    git checkout master &&
    test_push_failure simple &&
    test_push_failure upstream
'

test_expect_success 'push to existing branch, upstream configured with same name' '
    test_config branch.master.remote repo1 &&
    test_config branch.master.merge refs/heads/master &&
    git checkout master &&
    test_commit six &&
    test_push_success upstream master &&
    test_commit seven &&
    test_push_success simple master
'

test_expect_success 'push to existing branch, upstream configured with different name' '
    test_config branch.master.remote repo1 &&
    test_config branch.master.merge refs/heads/other-name &&
    git checkout master &&
    test_commit eight &&
    test_push_success upstream other-name &&
    test_commit nine &&
    test_push_failure simple &&
    git --git-dir=repo1 log -1 --format="%h %s" "other-name" >expect-other-name &&
    test_push_success current master &&
    git --git-dir=repo1 log -1 --format="%h %s" "other-name" >actual-other-name &&
    test_cmp expect-other-name actual-other-name
'

Если указана ваша восходящая ветка (git config branch.master.merge refs/heads/master), будет работать простая или восходящая политика pu sh. При условии, что имя ветки совпадает с восходящим.

upstream - pu sh текущая ветвь обратно в ветку, изменения которой обычно интегрируются в текущую ветвь (которая называется @{upstream}) . Этот режим имеет смысл только в том случае, если вы нажимаете на тот же репозиторий, из которого обычно извлекаете (т.е. центральный рабочий процесс). безопасность - отказать pu sh, если имя восходящей ветки отличается от локального.

Если вы думаете, что пограничный случай не покрывается этими тестами, новый git Команда bugreport (Git 2.27+) может пригодиться.