ОБНОВЛЕНИЕ: больше информации!
Я должен был сделать это с самого начала: я добавил примечания к выпуску 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) или подкоманды обновления git-remote (1) . & Mdash; документация 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) или подкоманды обновления 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 неясно, можно ли получить что-либо, кроме одной группы пультов с командой.
Wrapup
Как я объяснил, 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].