git-fetch

Получить данные со всех удалённых репозиториев, кроме тех, для которых задана переменная конфигурации remote.<name>.skipFetchAll. Переопределяет переменную конфигурации fetch.all.

Добавить имена ссылок и имена объектов полученных ссылок к существующему содержимому .git/FETCH_HEAD. Без этого параметра старые данные в .git/FETCH_HEAD будут перезаписаны.

Использовать атомарную транзакцию для обновления локальных ссылок. Либо обновляются все ссылки, либо при ошибке не обновляется ни одна.

Ограничить получение указанным числом коммитов от вершины истории каждой удалённой ветки. При получении в репозиторий shallow, созданный командой git clone с параметром --depth=<depth> (см. git-clone[1]), углубить или сократить историю до указанного числа коммитов. Теги для углублённых коммитов не загружаются.

Аналогично --depth, за исключением того, что задаётся число коммитов от текущей границы неглубокой истории, а не от вершины истории каждой удалённой ветки.

Углубить или сократить историю неглубокого репозитория, включив все достижимые коммиты после <date>.

Углубить или сократить историю неглубокого репозитория, исключив коммиты, достижимые из указанной удалённой ветки или тега. Этот параметр можно указать несколько раз.

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

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

По умолчанию при получении данных из неглубокого репозитория git fetch отклоняет ссылки, для обновления которых требуется изменить .git/shallow. Этот параметр обновляет .git/shallow и принимает такие ссылки.

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

--negotiation-restrict — предпочтительное имя этого параметра; --negotiation-tip принимается как синоним.

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

Аргументом этого параметра может быть шаблон glob для имён ссылок, ссылка или (возможно, сокращённый) SHA-1 коммита. Указание шаблона glob эквивалентно многократному указанию этого параметра — по одному разу для каждого подходящего имени ссылки.

См. также переменные конфигурации fetch.negotiationAlgorithm и push.negotiate, описанные в git-config[1], а также параметр --negotiate-only ниже.

Гарантировать, что коммиты в заданных вершинах всегда передаются в виде строк «have» во время согласования при получении данных, независимо от выбранного алгоритмом согласования. Это полезно, чтобы гарантировать учёт общей истории, достижимой из определённых ссылок, даже если --negotiation-restrict ограничивает набор вершин или алгоритм согласования иначе пропустил бы их.

Этот параметр можно указать несколько раз; в этом случае каждый коммит передаётся безусловно.

Аргументом может быть точное имя ссылки (например, refs/heads/release), хеш объекта или шаблон glob (например, refs/heads/release/{asterisk}). Синтаксис шаблонов совпадает с синтаксисом для --negotiation-restrict.

Если используется --negotiation-restrict, набор have сначала ограничивается этим параметром, а затем расширяется за счёт вершин, указанных с помощью --negotiation-include.

Если этот параметр не указан в командной строке, вместо него используются значения конфигурации remote.<name>.negotiationInclude для текущего удалённого репозитория.

Не получать с сервера никаких данных, а вместо этого вывести предков заданных аргументов --negotiation-restrict=, общих с сервером.

Несовместим с --recurse-submodules=(yes|on-demand). Внутри Git этот параметр используется для реализации параметра push.negotiate; см. git-config[1].

Показать, что было бы сделано, не внося никаких изменений.

Выводить результаты в стандартный поток вывода в удобном для обработки скриптами формате. Подробности см. в разделе OUTPUT в git-fetch[1].

Несовместим с --recurse-submodules=(yes|on-demand) и имеет приоритет над параметром конфигурации fetch.output.

Использовать возможность частичного клонирования и запросить у сервера подмножество достижимых объектов согласно заданному фильтру объектов. При использовании --filter предоставленное значение <filter-spec> используется для частичного получения данных.

Если используется --filter=auto, спецификация фильтра определяется автоматически путём объединения спецификаций фильтров, объявленных сервером для принимаемых клиентом удалённых promisor-репозиториев (см. gitprotocol-v2[5] и параметр конфигурации promisor.acceptFromServer в git-config[1]).

Подробное описание всех остальных доступных спецификаций фильтров см. в параметре --filter=<filter-spec> команды git-rev-list[1].

Например, --filter=blob:none отфильтрует все blob-объекты (содержимое файлов), пока они не понадобятся Git. Кроме того, --filter=blob:limit=<size> отфильтрует все blob-объекты размером не менее <size>.

Записать список полученных удалённых ссылок в файл FETCH_HEAD непосредственно в каталоге $GIT_DIR. Это поведение по умолчанию. Передача --no-write-fetch-head в командной строке указывает Git не записывать файл. При параметре --dry-run файл никогда не записывается.

При использовании git fetch со спецификацией ссылки <src>:<dst> команда может отказаться обновлять локальную ветку, как описано ниже в разделе <refspec>. Этот параметр отменяет эту проверку.

Сохранить загруженный pack-файл.

Разрешить указывать несколько аргументов <repository> и <group>. Аргументы <refspec> указывать нельзя.

Выполнить git maintenance run --auto в конце, чтобы при необходимости выполнить автоматическое обслуживание репозитория. По умолчанию этот параметр включён.

Записать граф коммитов после получения данных. Переопределяет настройку конфигурации fetch.writeCommitGraph.

Изменить настроенную спецификацию ссылок так, чтобы все ссылки помещались в пространство имён refs/prefetch/. См. задачу prefetch в git-maintenance[1].

Перед получением данных удалить все ссылки удалённого отслеживания, которых больше нет в удалённом репозитории. Теги не удаляются, если они получены только в результате автоматического следования тегам по умолчанию или из-за параметра --tags. Однако если теги получены по явной спецификации ссылок (в командной строке или в конфигурации удалённого репозитория, например, если удалённый репозиторий был клонирован с параметром --mirror), они также подлежат удалению. Указание --prune-tags — это сокращённая форма задания спецификации ссылки для тегов.

Подробности см. в разделе PRUNING ниже.

Перед получением данных удалить все локальные теги, которых больше нет в удалённом репозитории, если включён параметр --prune. Этот параметр следует использовать с осторожностью: в отличие от --prune, он удалит все созданные локальные ссылки (локальные теги). Этот параметр является сокращённой формой явного указания спецификации ссылки для тегов вместе с --prune; см. обсуждение этого параметра в его документации.

Подробности см. в разделе PRUNING ниже.

По умолчанию теги, указывающие на объекты, загружаемые из удалённого репозитория, также загружаются и сохраняются локально. Этот параметр отключает автоматическое следование тегам. Поведение удалённого репозитория по умолчанию можно задать с помощью настройки remote.<name>.tagOpt. См. git-config[1].

Вместо согласования с сервером, позволяющего избежать передачи уже имеющихся локально коммитов и связанных с ними объектов, этот параметр загружает все объекты, как при свежем клонировании. Используйте его, чтобы повторно применить фильтр частичного клонирования из конфигурации или заданный с помощью --filter=, если определение фильтра изменилось. Автоматическое обслуживание после получения данных выполнит консолидацию pack-файлов базы объектов, чтобы удалить дубликаты объектов.

При получении ссылок, перечисленных в командной строке, использовать указанную спецификацию ссылок (её можно задать несколько раз) для сопоставления ссылок с ветками удалённого отслеживания вместо значений переменных конфигурации remote.<name>.fetch для удалённого репозитория. Передача пустого значения <refspec> параметру --refmap заставляет Git игнорировать настроенные спецификации ссылок и полностью полагаться на спецификации, переданные аргументами командной строки. Подробности см. в разделе «Настроенные ветки удалённого отслеживания».

Получить все теги из удалённого репозитория (то есть получить удалённые теги refs/tags/* в локальные теги с теми же именами) в дополнение ко всему, что было бы получено в противном случае. Использование этого параметра само по себе не делает теги подлежащими удалению, даже если указан --prune (хотя теги всё равно могут быть удалены, если они также являются назначением явной спецификации ссылок; см. --prune).

Управлять тем, следует ли получать новые коммиты подмодулей и при каких условиях. При рекурсивном обходе подмодулей git fetch всегда пытается получить «изменённые» подмодули, то есть подмодули, содержащие коммиты, на которые ссылается вновь полученный коммит суперпроекта, но которых нет в локальном клоне подмодуля. Изменённый подмодуль можно получить, если он присутствует локально, например, в $GIT_DIR/modules/ (см. gitsubmodules[7]); если вышестоящий репозиторий добавляет новый подмодуль, его нельзя получить, пока он не будет клонирован, например, с помощью git submodule update.

При значении on-demand получаются только изменённые подмодули. При значении yes получаются все заполненные подмодули, а также незаполненные изменённые подмодули. При значении no подмодули никогда не загружаются.

Если параметр не указан, используется значение fetch.recurseSubmodules, если оно задано (см. git-config[1]); если нет, используется значение on-demand. Если этот параметр указан без значения, по умолчанию используется yes.

Выполнять все виды получения данных параллельно, запуская не более <n> задач одновременно.

Значение 0 означает использование подходящего значения по умолчанию.

Если указан параметр --multiple, разные удалённые репозитории будут опрашиваться параллельно. Если загружается несколько подмодулей, они также будут загружаться параллельно. Чтобы управлять ими независимо, используйте настройки конфигурации fetch.parallel и submodule.fetchJobs (см. git-config[1]).

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

Отключить рекурсивное получение данных подмодулей (это равносильно использованию параметра --recurse-submodules=no).

Если получение данных из удалённого репозитория прошло успешно, добавить вышестоящую (отслеживаемую) ссылку, используемую командами git-pull[1] без аргументов и другими командами. Дополнительные сведения см. в описании branch.<name>.merge и branch.<name>.remote в git-config[1].

Добавить <path> в начало путей, выводимых в информационных сообщениях, например «Получение данных подмодуля foo». Этот параметр используется внутри Git при рекурсивном обходе подмодулей.

Этот параметр используется внутри Git для временного задания неотрицательного значения по умолчанию для параметра --recurse-submodules. Все остальные способы настройки рекурсивного получения данных подмодулей (например, настройки в gitmodules[5] и git-config[1]) имеют приоритет над этим параметром, как и прямое указание --[no-]recurse-submodules.

По умолчанию git fetch отказывается обновлять ссылку HEAD, соответствующую текущей ветке. Этот флаг отключает проверку. Он предназначен исключительно для внутреннего использования, чтобы git pull могла взаимодействовать с git fetch; если вы не реализуете собственный Porcelain, использовать его не следует.

Если этот параметр задан и обработкой репозитория, из которого получают данные, занимается git fetch-pack, значение --exec=<upload-pack> передаётся команде, чтобы указать нестандартный путь к команде, запускаемой на другой стороне.

Передать --quiet команде git-fetch-pack и отключить вывод всех остальных внутренних команд git. Сведения о ходе выполнения не выводятся в стандартный поток ошибок.

Включить подробный вывод.

По умолчанию сведения о ходе выполнения выводятся в стандартный поток ошибок, если он подключён к терминалу, если только не указан параметр -q. Этот флаг принудительно включает вывод сведений о ходе выполнения, даже если стандартный поток ошибок не направлен в терминал.

Передать указанную строку серверу при взаимодействии с использованием версии 2 протокола. Указанная строка не должна содержать символ NUL или LF. Обработка сервером параметров, в том числе неизвестных, зависит от конкретного сервера. Если указано несколько параметров --server-option=<option>, все они передаются другой стороне в порядке, заданном в командной строке. Если в командной строке не указан ни один параметр --server-option=<option>, вместо них используются значения переменной конфигурации remote.<name>.serverOption.

По умолчанию Git проверяет, была ли ветка принудительно обновлена при получении данных. Эту проверку можно отключить с помощью fetch.showForcedUpdates, но параметр --show-forced-updates гарантирует её выполнение. См. git-config[1].

По умолчанию Git проверяет, была ли ветка принудительно обновлена при получении данных. Чтобы пропустить эту проверку ради повышения производительности, передайте --no-show-forced-updates или задайте для fetch.showForcedUpdates значение false. При использовании во время git-pull параметр --ff-only всё равно проверит наличие принудительных обновлений перед попыткой выполнить перемотку вперёд. См. git-config[1].

Использовать только адреса IPv4, игнорируя адреса IPv6.

Использовать только адреса IPv6, игнорируя адреса IPv4.

«Удалённый» репозиторий, являющийся источником операции получения данных или извлечения изменений. Этот параметр может быть URL-адресом (см. раздел АДРЕСА GIT ниже) или именем удалённого репозитория (см. раздел УДАЛЁННЫЕ РЕПОЗИТОРИИ ниже).

Имя, указывающее на список репозиториев, заданный значением remotes.<group> в файле конфигурации. (См. git-config[1].)

Указывает, какие ссылки получать и какие локальные ссылки обновлять. Если в командной строке не указано ни одного <refspec>, ссылки для получения считываются вместо этого из переменных remote.<repository>.fetch (см. раздел НАСТРОЕННЫЕ ВЕТКИ ОТСЛЕЖИВАНИЯ УДАЛЕННЫХ РЕПОЗИТОРИЕВ ниже).

Формат параметра <refspec> — необязательный знак плюс +, за которым следует исходная <src>, двоеточие :, а затем целевая <dst>. Двоеточие можно опустить, если <dst> — пустое. Обычно <src> — это ссылка или шаблон glob с одним символом *, который используется для сопоставления набора ссылок, но это также может быть полностью записанное шестнадцатеричное имя объекта.

<refspec> может содержать * в своей <src> для указания простого сопоставления с шаблоном. Такая спецификация ссылки работает как шаблон glob, соответствующий любой ссылке с этим шаблоном. Шаблон <refspec> должен содержать ровно один символ * как в <src>, так и в <dst>. Ссылки будут сопоставлены с назначением путём замены * содержимым, соответствующим источнику.

Если перед спецификацией ссылки стоит ^, она интерпретируется как отрицательная спецификация ссылки. Вместо указания ссылок для получения или локальных ссылок для обновления такая спецификация указывает ссылки, которые следует исключить. Ссылка считается соответствующей, если она соответствует хотя бы одной положительной спецификации ссылки и не соответствует ни одной отрицательной. Отрицательные спецификации ссылок могут быть полезны для ограничения области действия шаблона, чтобы в неё не попадали определённые ссылки. Отрицательные спецификации ссылок сами могут быть шаблонами. Однако они могут содержать только <src> и не указывают <dst>. Полностью записанные шестнадцатеричные имена объектов также не поддерживаются.

tag <tag> означает то же, что и refs/tags/<tag>:refs/tags/<tag>; эта команда запрашивает получение всех объектов вплоть до указанной метки.

Удалённая ссылка, соответствующая <src>, будет получена; если <dst> не является пустой строкой, будет предпринята попытка обновить соответствующую ей локальную ссылку.

Возможность выполнить это обновление без --force зависит от пространства имён ссылок, в которое выполняется получение, типа получаемого объекта и того, считается ли обновление перемоткой вперёд. В целом для получения действуют те же правила, что и для отправки; см. раздел <refspec>... в git-push[1], где они описаны. Ниже перечислены исключения из этих правил, относящиеся именно к git fetch.

До версии Git 2.20, в отличие от отправки с помощью git-push[1], любые обновления refs/tags/* принимались без + в спецификации ссылки (или --force). При получении все обновления меток с удалённого репозитория без разбора считались принудительными. Начиная с Git версии 2.20 получение для обновления refs/tags/* работает так же, как отправка. То есть любые обновления будут отклонены без + в спецификации ссылки (или --force).

В отличие от отправки с помощью git-push[1], любые обновления за пределами refs/{tags,heads}/* принимаются без + в спецификации ссылки (или --force), будь то замена, например, объекта дерева на объект blob или одного коммита другим коммитом, у которого предыдущий коммит не является предком, и т. д.

В отличие от отправки с помощью git-push[1], не существует настройки, которая изменяла бы эти правила, и нет аналога хука pre-fetch, подобного хуку pre-receive.

Как и при отправке с помощью git-push[1], все описанные выше правила о недопустимых обновлениях можно переопределить, добавив необязательный начальный символ + к спецификации ссылки (или используя параметр командной строки --force). Единственное исключение: никакая принудительная операция не заставит пространство имён refs/heads/* принять объект, не являющийся коммитом.

Считывать спецификации ссылок, по одной на строку, из стандартного ввода в дополнение к указанным в аргументах. Формат «tag <name>» не поддерживается.

Один символ, указывающий состояние ссылки:

Для успешно полученной ссылки в сводке отображаются её старое и новое значения в формате, подходящем для использования в качестве аргумента команды git log (в большинстве случаев это <old>..<new>, а при принудительных обновлениях без перемотки вперёд — <old>...<new>).

Имя получаемой удалённой ссылки без префикса refs/<type>/. При удалении имя удалённой ссылки — "(none)".

Имя обновляемой локальной ссылки без префикса refs/<type>/.

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

Этот параметр определяет, будут ли команды git fetch (и выполняемая ими команда получения данных git pull) рекурсивно получать данные во вложенные модули, содержимое которых уже получено. Для этого параметра можно задать логическое значение или значение on-demand. Логическое значение меняет поведение команд fetch и pull: при значении true рекурсивный обход вложенных модулей выполняется безусловно, а при значении false не выполняется вовсе. При значении on-demand команды fetch и pull выполняют рекурсивный обход только тех вложенных модулей, содержимое которых уже получено, если суперпроект получает коммит, обновляющий ссылку вложенного модуля. По умолчанию используется значение on-demand или значение submodule.recurse, если оно задано.

Если задано значение true, git-fetch-pack проверит все полученные объекты. Описание проверок см. в transfer.fsckObjects. По умолчанию используется значение false. Если параметр не задан, вместо него используется значение transfer.fsckObjects.

Работает как fsck.<msg-id>, но используется командой git-fetch-pack[1], а не командой git-fsck[1]. Подробности см. в документации fsck.<msg-id>.

Работает как fsck.skipList, но используется командой git-fetch-pack[1], а не командой git-fsck[1]. Подробности см. в документации fsck.skipList.

Если число объектов, полученных посредством нативного протокола передачи Git, меньше этого предела, они будут распакованы в отдельные файлы объектов. Если же число полученных объектов равно этому пределу или превышает его, полученный пакет будет сохранён как пакет после добавления всех недостающих баз дельт. Сохранение пакета при отправке данных может ускорить завершение операции отправки, особенно на медленных файловых системах. Если параметр не задан, используется значение transfer.unpackLimit.

Если задано значение true, команда fetch будет автоматически вести себя так, как если бы в командной строке был указан параметр --prune. См. также remote.<name>.prune и раздел PRUNING справочной страницы git-fetch[1].

Если задано значение true, при удалении ссылок команда fetch будет автоматически вести себя так, как если бы была указана спецификация ссылки refs/tags/*:refs/tags/*, если она ещё не задана. Это позволяет использовать одновременно данный параметр и fetch.prune, чтобы поддерживать соответствие ссылок вышестоящего репозитория по схеме 1=1. См. также remote.<name>.pruneTags и раздел PRUNING справочной страницы git-fetch[1].

Если задано значение true, команда fetch попытается обновить все доступные удалённые репозитории. Это поведение можно переопределить, указав --no-all или явно задав один или несколько удалённых репозиториев, из которых нужно получить данные. По умолчанию используется значение false.

Управляет выводом состояния обновления ссылок. Допустимые значения: full и compact. Значение по умолчанию — full. Подробности см. в разделе OUTPUT справочной страницы git-fetch[1].

Управляет тем, как при согласовании содержимого отправляемого сервером файла пакета передаются сведения о коммитах в локальном репозитории. Укажите consecutive, чтобы использовать алгоритм, который проходит по последовательным коммитам и проверяет каждый из них. Укажите skipping, чтобы использовать алгоритм, пропускающий коммиты для ускорения согласования, но способный привести к созданию избыточно большого файла пакета; либо укажите noop, чтобы не отправлять сведения вовсе. Последний вариант почти наверняка приведёт к созданию избыточно большого файла пакета, но позволит пропустить этап согласования. Укажите default, чтобы отменить ранее заданные параметры и использовать поведение по умолчанию. Обычно по умолчанию используется значение consecutive, но если feature.experimental имеет значение true, по умолчанию используется значение skipping. Неизвестное значение приведёт к ошибке команды git fetch.

См. также параметры --negotiate-only и --negotiation-restrict команды git-fetch[1].

Задайте значение false, чтобы включить --no-show-forced-updates в командах git-fetch[1] и git-pull[1]. По умолчанию используется значение true.

Задаёт максимальное количество операций получения данных, выполняемых одновременно (для вложенных модулей или удалённых репозиториев, если действует параметр --multiple команды git-fetch[1]).

Значение 0 задаёт разумный предел по умолчанию. Если параметр не задан, используется значение 1.

Для вложенных модулей это значение можно переопределить с помощью параметра конфигурации submodule.fetchJobs.

Задайте значение true, чтобы создавать граф коммитов после каждой команды git fetch, загружающей файл пакета из удалённого репозитория. При использовании параметра --split большинство запусков создаёт очень небольшой файл графа коммитов поверх существующих файлов графа коммитов. Иногда эти файлы объединяются, и запись может занять больше времени. Обновлённый файл графа коммитов ускоряет работу многих команд Git, включая git merge-base, git push -f и git log --graph. По умолчанию используется значение false.

В этом параметре хранится URI для загрузки данных объектов Git из bundle URI перед инкрементальным получением данных с исходного сервера Git. Это работает аналогично параметру --bundle-uri команды git-clone[1]. Команда git clone --bundle-uri задаст значение fetch.bundleURI, если указанный bundle URI содержит список пакетов, организованный для инкрементального получения данных.

Если изменить это значение, а в вашем репозитории задано значение fetch.bundleCreationToken, удалите это значение fetch.bundleCreationToken перед получением данных из нового bundle URI.

При использовании fetch.bundleURI для инкрементального получения данных из списка пакетов, использующего эвристику «creationToken», в этом параметре конфигурации хранится максимальное значение creationToken среди загруженных пакетов. Это значение предотвращает загрузку пакетов в будущем, если объявленное значение creationToken не превышает его.

Значения токенов создания выбирает поставщик, обслуживающий соответствующий bundle URI. Если изменить URI в параметре fetch.bundleURI, перед получением данных обязательно удалите значение параметра fetch.bundleCreationToken.