Git fetch и потянуть без аргументов

Ответ 1

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

Вы можете понять это из справочной страницы git pull, как я описал ниже, но обычно я старался не выполнять эту работу: git fetch origin, а затем git merge origin/foo. (Я написал несколько бессвязное сообщение в блоге об этом.)

Однако ваш вопрос действительно касается поведения по умолчанию git pull, когда вы не указываете удаленный или refspec. Мы можем понять это из git pull man page и, в частности, DEFAULT BEHAVIOUR. Это сложно понять, поэтому я выделил только те части, которые действительно применимы к вашему вопросу, учитывая, что (a) вы находитесь на ветке foo, (b) вы создали эту ветку, как вы описали в вопрос, и (c) вы не меняли конфигурацию.

Часто люди используют git pull без предоставления каких-либо параметров. Традиционно это эквивалентно высказыванию git pull origin. Однако, когда конфигурация branch.<name>.remote присутствует, а на ветке <name> это значение используется вместо origin.

Чтобы определить, какой URL использовать для извлечения, используется значение конфигурации remote.<origin>.url, и если такой переменной нет, используется значение в строке URL: в файле $GIT_DIR/remotes/<origin>.

Чтобы определить, какие удаленные ветки извлекать (и, возможно, хранить в ветвях удаленного отслеживания), когда команда запускается без каких-либо параметров refspec в командной строке, запрашиваются значения переменной конфигурации remote.<origin>.fetch, и если там arent любой, $GIT_DIR/remotes/<origin> файл, и его линии Pull: используются. В дополнение к форматам refspec, описанным в разделе OPTIONS, вы можете иметь рефлектометр globbing, который выглядит следующим образом:

refs/heads/*:refs/remotes/origin/*

В рефлексии globbing должен быть непустой RHS (т.е. должен хранить то, что было выбрано в ветвях удаленного отслеживания), а его LHS и RHS должны заканчиваться на /*. Вышеописанное указывает, что все удаленные ветки отслеживаются с помощью ветвей удаленного отслеживания в иерархии refs/remotes/origin/ под тем же именем.

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

Если в командной строке git pull были указаны явные refspecs, все они слиты.

Если в командной строке не было указано refspec, то git pull использует refspec из конфигурации или $GIT_DIR/remotes/<origin>. В таких случаях применяются следующие правила:

• If branch.<name>.merge Конфигурация для текущей ветки существует, то есть имя ветки на удаленном сайте, который был объединен.

• Если refspec является глобирующим, ничего не сливается.

• В противном случае удаленная ветвь первого refspec будет объединена.

Когда вы создали ветвь foo с помощью:

git checkout origin/foo -b foo --track

... он установит следующие параметры конфигурации, которые связывают вашу ветку foo с refs/heads/foo в репозитории origin:

branch.foo.remote=origin
branch.foo.merge=refs/heads/foo

Итак, если вы положите это вместе с ободренными предложениями выше, ответ будет "Да, в этой ситуации вы описываете, когда вы находитесь на ветке foo, команды git pull и git pull origin foo эквивалентны."

Ответ 2

Даже в условиях, которые Марк описывает, когда они кажутся одинаковыми, все еще есть тонкая разница - git pull origin foo не будет обновлять ветвь удаленного отслеживания, тогда как git pull будет. Это описано в man-странице для git -pull:

A parameter <ref> without a colon is equivalent to <ref>: when pulling/fetching, so it merges <ref> into the current branch without storing the remote branch anywhere locally

Итак, в вашем случае для истинного эквивалента git pull вам нужно сделать git pull origin foo:refs/remotes/origin/foo

Ответ 3

Да, они есть. Информация отслеживания сохраняется в .git/config.