Почему я должен " git push --set-upstream origin "?

Я создал локальную ветку для тестирования Solaris и Sun Studio. Затем я толкнул ветку вверх по течению. После совершения изменения и попытки подтолкнуть изменения:

$ git commit blake2.cpp -m "Add workaround for missing _mm_set_epi64x"
[solaris 7ad22ff] Add workaround for missing _mm_set_epi64x
 1 file changed, 5 insertions(+)
$ git push
fatal: The current branch solaris has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin solaris

почему я должен делать что-то особенное для этого?

есть ли разумный случай использования, когда кто-то создаст <branch>, нажмите <branch> удаленному, а затем требовать фиксации на <branch> не должно быть <branch>?

я последовал за этим вопросом и ответом на Переполнение Стека:нажмите новую локальную ветвь в удаленный репозиторий Git и отследите ее тоже. Я предполагаю, что это еще один пример неполного или неправильного принятого ответа. Или это еще один пример того, как Git берет простую задачу и делает ее сложной.

вот вид на другой машине. Ветвь явно существует, поэтому ее создали и подтолкнули:

$ git branch -a
  alignas
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/alignas
  remotes/origin/arm-neon
  remotes/origin/det-sig
  remotes/origin/master
  remotes/origin/solaris
32
branch git

2 ответов

TL; DR:git branch --set-upstream-to origin/solaris

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

если у вас нет upstream для текущей ветви, однако, Git изменяет свое поведение на git push, а также по другим командам.

полная история толчка здесь длинная и скучная и возвращается в историю до версии Git 1.5. Чтобы сократить его на целую кучу,git push была реализована плохо.1 начиная с Git версии 2.0, Git теперь имеет ручку конфигурации по буквам push.default что теперь по умолчанию:simple. Несколько версий Git до и после 2.0, Каждый раз, когда вы запускали git push, Git будет извергать много шума, пытаясь убедить вас установить push.default хотя бы git push заткнуться.

вы не упоминаете, какую версию Git вы используете, ни настроили ли вы push.default, так надо догадаться. Я предполагаю, что вы используете Git версии 2-point-something, и что вы установили push.default to simple чтобы заставить его заткнуться. Именно какая версия Git у вас есть, и что, если что-нибудь у вас есть push.default установлено, тут дело, из-за этой долгой и скучной истории, но в конце концов, тот факт, что вы получаете еще одну жалобу от Git, указывает на то, что ваш Git is настроено, чтобы избежать одной из ошибок прошлое.

что такое вверх по течению?

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

каждая ветвь имеет возможность иметь один (1) набор вверх по течению. То есть каждая ветвь либо имеет восходящее течение, либо не имеет восходящего. Ни одна ветвь не может иметь больше одной вверх по течению.

верховье должны, но не должно быть, допустимая ветвь (будь то удаленное отслеживание, как origin/B или местного типа master). То есть, если текущая ветвь B имеет вверх по течению U, git rev-parse U должны работа. Если он не работает-если он жалуется, что U не существует-тогда большая часть Git действует так, как будто восходящий поток не установлен вообще. Несколько команд, например git branch -vv, покажет настройку вверх по течению, но пометит его как "ушел".

что хорошего апстрим?

если push.default установлено значение simple или upstream, настройка вверх по течению сделает git push, используется без дополнительных аргументов, просто работать.

это все-это все, что он делает для git push. Но это довольно значительно, так как git push это одно из мест, где простая опечатка вызывает серьезные головные боли.

если push.default установлено значение nothing, matching или current, установка вверх по течению ничего не делает для git push.

(все это предполагает, что ваша версия Git по крайней мере 2.0.)

вверх по течению влияет git fetch

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

вверх по течению влияет git merge и git rebase слишком

если вы запустите git merge или git rebase без дополнительных аргументов Git использует текущую ветвь вверх по течению. Таким образом, это сокращает использование этих двух команд.

вверх по течению влияет git pull

вы никогда не должны2 использовать git pull в любом случае, но если вы git pull использует настройку вверх по течению, чтобы выяснить, какой пульт для извлечения, а затем какой ветвь для слияния или перебазирования. То есть, git pull делает то же самое как git fetch - потому что это на самом деле работает git fetch - а затем делает то же самое, что и git merge или git rebase, потому что это на самом деле работает git merge или git rebase.

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

вверх по течению влияет git status

это на самом деле может быть самым важным. Как только у вас есть восходящий набор,git status может сообщить о разнице между вашей текущей веткой и ее восходящей веткой с точки зрения коммитов.

если, как это обычно бывает, вы находитесь на ветке B с его вверх по течению установлен в origin/B, а вы бегите git status, вы сразу увидите, есть ли у вас коммиты, которые вы можете нажать, и / или коммиты, которые вы можете объединить или перебазировать.

это так git status работает:

  • git rev-list --count @{u}..HEAD: сколько коммитов у вас есть на B, не на origin/B?
  • git rev-list --count HEAD..@{u}: сколько коммитов у вас есть на origin/B, не на B?

установка вверх по течению дает вам все эти вещи.

почему master уже имеет вверх по течению набор?

при первом клонировании с некоторого пульта, используя:

$ git clone git://some.host/path/to/repo.git

или аналогичный, последний шаг Git делает, по сути,git checkout master. Это проверяет ваш местный филиал master-только ты не есть местное отделение master.

с другой стороны, вы do есть ветка удаленного отслеживания с именем origin/master, потому что вы только что клонировали его.

Git догадывается, что вы, должно быть, имели в виду: "сделайте мне новый местный master это указывает на ту же фиксацию, что и удаленное отслеживание origin/master, и, пока вы на нем, установите вверх по течению для master to origin/master."

это произойдет для филиала git checkout которого у вас еще нет. Git создает филиала и делает его "дорожкой" (имеет в качестве восходящего) соответствующую ветку удаленного отслеживания.

но это не работает для new ветви, т. е. ветви без отделение дистанционного слежения пока.

если вы создадите new отрасли:

$ git checkout -b solaris

пока нет origin/solaris. Ваш местный solaris не может отслеживать дистанционное отслеживание ветви origin/solaris потому что его не существует.

при первом нажатии на новую ветку:

$ git push origin solaris

это создает solaris on origin, и, следовательно, создает origin/solaris в вашем собственном Git хранилище. Но слишком поздно: у вас уже есть местный solaris это не имеет вверх по течению.3

не должен ли Git просто установить это, теперь, как вверх по течению автоматически?

наверное. См. "плохо реализовано" и сноску 1. Это трудно изменить теперь миллионы4 скриптов, которые используют Git и некоторые из них, вполне могут зависеть от его текущего поведения. Изменение поведения требует нового основного отпустите, nag-ware, чтобы заставить вас установить некоторое поле конфигурации и так далее. Короче говоря, Git-жертва собственного успеха: какие бы ошибки он ни совершал сегодня, они могут быть исправлены только в том случае, если изменения либо в основном невидимы, явно-намного-лучше, либо делаются медленно с течением времени.

дело в том, что сегодня это не так,если вы используете --set-upstream или -u во время git push. Вот что говорится в послании.

вы не должны делать это. Ну, как мы уже отмечали выше, вам совсем не обязательно это делать, но допустим, вы хочу вышестоящим. Вы уже создали ветку solaris on origin, через более ранний толчок, и как ваш git branch вывод показывает, что вы уже есть origin/solaris в вашем локальном репозитории.

у вас просто нет его в качестве восходящего для solaris.

, чтобы установить его сейчас, а не во время первого толчка, используйте git branch --set-upstream-to. The --set-upstream-to суб-команды принимает имя любой существующей ветви, например origin/solaris, и устанавливает текущую ветвь вверх по течению к этой другой ветви.

это все-это все, что он делает-но у него есть все эти последствия, отмеченные выше. Это означает, что вы можете просто запустить git fetch, затем осмотритесь, затем бегите git merge или git rebase при необходимости, затем сделайте новые коммиты и запустите git push, без дополнительной суеты вокруг.

1справедливости ради, тогда еще не было ясно что первоначальная реализация была подвержена ошибкам. Это стало ясно только тогда, когда каждый новый пользователь делал одни и те же ошибки каждый раз. Теперь он "менее беден", что не означает"Великий".

2 "никогда" немного сильно, но я нахожу, что новички Git понимают вещи намного лучше, когда я отделяю шаги, особенно когда я могу показать им, что git fetch на самом деле сделал, и они могут видеть то, что git merge или git rebase будет делать следующий.

3если вы запустите свой первый git push as git push -u origin solaris - то есть, если вы добавите -u флаг-Git будет установлен origin/solaris как вверх по течению для вашей текущей ветви, если (и только если) толчок удастся. Поэтому вы должны поставить -u на первый пуш. На самом деле, вы можете поставить его на любой более поздний толчок, и он будет установлен изменить вверх по течению в этой точке. Но я думаю ... --84--> легче, если вы забытого.

4измеряется методом Austin Powers / Dr Evil, просто говоря "один MILLLL-YUN", во всяком случае.

80

в основном полная команда похожа на git push <remote> <local_ref>:<remote_ref>. Если вы бежите просто git push, git не знает, что делать, если вы не сделали некоторую конфигурацию, которая помогает git принять решение. В репозитории git мы можем настроить несколько пультов. Также мы можем подтолкнуть локальный ref к любому удаленному ref. Полная команда-это самый простой способ сделать толчок. Если вы хотите ввести меньше слов, вам нужно сначала настроить, например --set-upstream.

4