Различия между удаленным обновлением и получением git?

Это git remote updateэквивалент git fetch?

ОБНОВЛЕНИЕ: больше информации!

Я должен был сделать это с самого начала: я добавил примечания к выпуску Git в Git-репозитории Git (так что, мета!)

grep --color=always -R -C30 fetch Documentation/RelNotes/* | less

Затем я выполнил lessпоиск --all, и вот что я нашел в заметках о выпуске для Git версии 1.6.6 :

git fetchузнал --allи --multipleопции, чтобы запустить выборку из многих репозиториев, а также --pruneвозможность удалить удаленные отслеживания ветви, которые устарели. Это делает git remote updateи git remote pruneменее необходимым (нет плана, чтобы удалить remote updateни remote prune, хотя).

Версия 1.6.6 не была выпущена до 23 декабря 2009 года , и оригинальный постер задал свой вопрос 6 декабря 2009 года.

Как видно из примечаний к выпуску, авторам Git было известно о том, что git remote updateфункциональность команды несколько дублировалась git fetch, но они решили не удалять ее, возможно, для обратной совместимости с существующими скриптами и программами, или, возможно, потому что это просто слишком много работы и есть предметы с более высоким приоритетом.

Оригинальный ответ с более подробной информацией

Ответ xenoterracide в 3,5 лет теперь, и Git прошел несколько версий с тех пор (он ушел от v1.6.5.5 до v1.8.3.2 на момент написания статьи), и , глядя на текущей документации git remote updateи git fetchэто выглядит как они оба могут выполнять в основном одну и ту же функцию извлечения новых коммитов с нескольких пультов , учитывая правильные параметры и аргументы.

Выборка всех пультов

Один из способов получить несколько пультов - с помощью --allфлага:

git fetch --all

Это будет выборка со всех настроенных вами пультов, при условии, что вы не remote.<name>.skipFetchAllнастроили для них:

Если true, этот удаленный будет пропущен по умолчанию при обновлении с использованием git-fetch (1) или подкоманды update git-remote (1) . - git-config документация

Это было бы эквивалентно использованию

git remote update

без указания какой-либо удаленной группы для извлечения, а также без указания remotes.defaultв вашей конфигурации репо, а также того, что ни один из ваших пультов не имеет remote.<name>.skipDefaultUpdateзначение true.

Текущая 1.8.3.2 документации для конфигурации Git и не упоминает remotes.defaultнастройки, но я консультировался Всемогущий Google об этом и нашел это полезное объяснение от Mislav Marohnić :

$ git config remotes.default 'origin mislav staging'
$ git remote update

# fetches remotes "origin", "mislav", and "staging"

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

Таким образом, по-видимому, если вы remotes.defaultустановили, и не все ваши пульты перечислены в нем, то git remote updateвы не получите все пульты, о которых ваше хранилище «знает».

Что касается remote.<name>.skipDefaultUpdateнастройки, Git docs объясняет это так:

Если true, этот удаленный будет пропущен по умолчанию при обновлении с использованием git-fetch (1) или подкоманды update git-remote (1) .

Извлечение указанной группы пультов

Вместо получения всех пультов ДУ, так fetchи remote updateпозволяют указать несколько пультов ДУ и группы пультов ДУ для извлечения:

git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository> | <group>)…]

git fetch [<options>] <group>позволяет выбрать несколько пультов, входящих в группу (позаимствовать другой пример у Mislav ):

$ git config remotes.mygroup 'remote1 remote2 ...'
$ git fetch mygroup

git fetch --multipleпозволяет указать несколько репозиториев и групп репозиториев для выборки одновременно (из документов ):

Разрешить несколько <repository>и <group>аргументы должны быть указаны. Нет <refspec>sможет быть указано.

Неоднозначность в git remote updateдокументации

Синопсис дляgit remote update специфицирует , что синтаксис команды выглядит следующим образом :

git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…]

Обратите внимание на последнюю часть [(<group> | <remote>)…]? Конечные точки ...подразумевают, что вы можете указать несколько групп и пультов с помощью команды, что будет означать, что она ведет себя так же, как git fetch --multiple... Посмотрите, как синтаксис между ними так похож?

Однако в том же документе объяснение updateкоманды ничего не говорит об указании нескольких групповых и удаленных аргументов, только то, что

Выбрать [es] обновления для именованного набора удаленных устройств в хранилище, как определено remotes.<group>.

Поэтому неясно, git remote updateработает ли идентично в git fetch --multipleотношении указания нескольких отдельных пультов и нескольких удаленных групп.

Выбор одного пульта

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

git fetch <remote>

Возможно, вы также можете использовать

git remote update <remote>

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

Заворачивать

Как я уже объяснил, git fetchи git remote updateведут себя аналогично в отношении выборки с нескольких пультов. Они имеют схожий синтаксис и аргументы, хотя git fetchи короче, поэтому людям, вероятно, будет проще печатать и использовать.

Это может быть случай, который git remote updateне может быть использован для извлечения только одного пульта, как с git fetch, но, как я указал, документация не проясняет это.

В стороне

Дублирование в функциональности между командами Git фарфор, примером которого git fetchи git remote updateвыше, не является уникальным. Я заметил аналогичную ситуацию с git rebase --ontoи git cherry-pick, в которой оба могут принять ряд коммитов для обновления на новый базовый коммит.

Я предполагаю, что по мере того, как Git развивался на протяжении многих лет, некоторые функции (неизбежно?) Дублировались, возможно, иногда для удобства конечных пользователей (например, проще передавать диапазон cherry-pick, чем передавать один коммит снова и снова выбрать диапазон). Очевидно cherry-pick, не всегда принимал диапазон коммитов , как объяснено в примечаниях к выпуску v1.7.2 :

git cherry-pickнаучился выбирать диапазон коммитов (например, cherry-pick A..Bи cherry-pick --stdin) git revert; однако они не поддерживают более приятный контроль секвенирования rebase [-i].

Да и нет. git remote updateвыборки со всех пультов, а не только с одного.

Не глядя на код, чтобы увидеть, remote updateявляется ли это только сценарий оболочки (возможно), он, в основном, запускает выборку для каждого пульта. git fetchможет быть гораздо более гранулированным.