Русский ▾ Topics ▾ Latest version ▾ git-p4 last updated in 2.52.0

НАЗВАНИЕ

git-p4 — Импорт из репозиториев Perforce и отправка в них

ОБЗОР

git p4 clone [<параметры-синхронизации>] [<параметры-клонирования>] <путь-к-p4-депо>…​
git p4 sync [<параметры-синхронизации>] [<путь-к-p4-депо>…​]
git p4 rebase
git p4 submit [<параметры-отправки>] [<имя-главной-ветки>]

ОПИСАНИЕ

Эта команда предоставляет способ взаимодействия с репозиториями p4 с использованием Git.

Создаёт новый репозиторий Git из существующего репозитория p4 с помощью git p4 clone, указывая ему один или несколько путей в депо p4. Включает новые коммиты из изменений p4 с помощью git p4 sync. Команда sync также используется для включения новых веток из других путей в депо p4. Отправляет изменения Git обратно в p4 с помощью git p4 submit. Команда git p4 rebase выполняет синхронизацию и перемещает текущую ветку поверх обновлённой внешней ветки p4.

ПРИМЕРЫ

  • Клонировать репозиторий:

    $ git p4 clone //depot/путь/проект

  • Выполнить некоторую работу во вновь созданном репозитории Git:

    $ cd проект
$ vi foo.h
$ git commit -a -m "отредактирован foo.h"

  • Обновить репозиторий Git последними изменениями из p4, перемещая вашу работу поверх:

    $ git p4 rebase

  • Отправить ваши коммиты обратно в p4:

    $ git p4 submit

КОМАНДЫ

Клон

Как правило, git p4 clone используется для создания нового каталога Git из существующего репозитория p4:

$ git p4 clone //depot/путь/проект

Этот:

  1. Создаёт пустой репозиторий Git в подкаталоге с именем проект.

  2. Импортирует полное содержимое головной редакции из указанного пути в депо p4 в один коммит в ветке Git refs/remotes/p4/master.

  3. Создаёт локальную ветку master из этого внешнего репозитория и переключает её.

Чтобы воспроизвести всю историю p4 в Git, используйте модификатор @all в пути депо:

$ git p4 clone //depot/путь/проект@all

Синхронизация

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

$ git p4 sync

Эта команда находит новые изменения в p4 и импортирует их как коммиты Git.

Репозитории P4 также могут быть добавлены в существующий репозиторий Git с помощью git p4 sync:

$ mkdir repo-git
$ cd repo-git
$ git init
$ git p4 sync //путь/в/вашем/perforce/депо

Это импортирует указанное депо в refs/remotes/p4/master в существующий репозиторий Git. Параметр --branch можно использовать для указания другой ветки для содержимого p4.

Если репозиторий Git включает ветки refs/remotes/origin/p4, они будут получены и проверены в первую очередь во время git p4 sync. Поскольку импорт непосредственно из p4 значительно медленнее, чем получение изменений из внешнего репозитория Git, это может быть полезно в среде с несколькими разработчиками.

Если есть несколько веток, выполнение git p4 sync автоматически использует алгоритм "ОБНАРУЖЕНИЕ ВЕТОК", чтобы попытаться распределить новые изменения по правильным веткам. Это можно переопределить с помощью параметра --branch, чтобы указать только одну ветку для обновления.

Перебазировать

Распространённый рабочий шаблон — получить последние изменения из депо p4 и слить их с локальными незафиксированными изменениями. Часто репозиторий p4 является конечным местом для всего кода, поэтому рабочий процесс с перемещением имеет смысл. Эта команда выполняет git p4 sync, а затем git rebase, чтобы переместить локальные коммиты поверх обновлённых изменений p4.

$ git p4 rebase

Отправка

Отправка изменений из репозитория Git обратно в репозиторий p4 требует отдельного рабочего пространства клиента p4. Это должно быть указано с помощью переменной среды P4CLIENT или переменной конфигурации Git git-p4.client. Клиент p4 должен существовать, но корень клиента будет создан и заполнен, если он ещё не существует.

Чтобы отправить все изменения, которые находятся в текущей ветке Git, но не в ветке p4/master, используйте:

$ git p4 submit

Чтобы указать ветку, отличную от текущей, используйте:

$ git p4 submit тематическая-ветка

Чтобы указать один коммит или диапазон коммитов, используйте:

$ git p4 submit --commit <sha1>
$ git p4 submit --commit <sha1..sha1>

Вышестоящая ссылка обычно refs/remotes/p4/master, но может быть переопределена с помощью параметра командной строки --origin=.

Изменения p4 будут созданы от имени пользователя, вызывающего git p4 submit. Параметр --preserve-user приведёт к изменению владельца в соответствии с автором коммита Git. Этот параметр требует прав администратора в p4, которые могут быть предоставлены с помощью p4 protect.

Чтобы отложить изменения вместо отправки, используйте --shelve и --update-shelve:

$ git p4 submit --shelve
$ git p4 submit --update-shelve 1234 --update-shelve 2345

Забрать из ящика

Снятие с полки возьмёт отложенный список изменений P4 и создаст эквивалентный коммит git в ветке refs/remotes/p4-unshelved/<список-изменений>.

Коммит git создаётся относительно текущей редакции origin (по умолчанию HEAD). Родительский коммит создаётся на основе origin, а затем на его основе создаётся коммит unshelve.

Редакцию origin можно изменить с помощью параметра "--origin".

Если целевая ветка в refs/remotes/p4-unshelved уже существует, старая будет переименована.

$ git p4 sync
$ git p4 unshelve 12345
$ git show p4-unshelved/12345
<отправить больше изменений через p4 в те же файлы>
$ git p4 unshelve 12345
<отказывается снимать с полки, пока git снова не синхронизируется с p4>

ПАРАМЕТРЫ

Общие параметры

Все команды, кроме clone, принимают эти параметры.

--git-dir <каталог>

Установить переменную окружения GIT_DIR. См. git[1].

-v
--verbose

Предоставлять больше информации о ходе выполнения.

Параметры синхронизации

Эти параметры могут использоваться как в начальном clone, так и в последующих операциях sync.

--branch <ссылка>

Импортировать изменения в <ссылка> вместо refs/remotes/p4/master. Если <ссылка> начинается с refs/, она используется как есть. В противном случае, если она не начинается с p4/, добавляется этот префикс.

По умолчанию <ссылка>, не начинающаяся с refs/, рассматривается как имя отслеживаемой внешней ветки (в refs/remotes/). Это поведение можно изменить с помощью параметра --import-local.

Значение по умолчанию для <ссылка> — "master".

Этот пример импортирует новый внешний репозиторий "p4/proj2" в существующий репозиторий Git:

    $ git init
    $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
--detect-branches

Использовать алгоритм обнаружения веток для поиска новых путей в p4. Он описан ниже в разделе "ОБНАРУЖЕНИЕ ВЕТОК".

--changesfile <файл>

Импортировать точно номера изменений p4, перечисленные в файле, по одному на строку. Обычно git p4 проверяет текущее состояние репозитория p4 и обнаруживает изменения, которые следует импортировать.

--silent

Не выводить никакой информации о ходе выполнения.

--detect-labels

Запрашивать в p4 метки, связанные с путями депо, и добавлять их как метки в Git. Ограниченная полезность, поскольку импортирует только метки, связанные с новыми списками изменений. Устарело.

--import-labels

Импортировать метки из p4 в Git.

--import-local

По умолчанию ветки p4 хранятся в refs/remotes/p4/, где они будут рассматриваться как отслеживаемые внешние ветки командами git-branch[1] и другими. Этот параметр вместо этого помещает ветки p4 в refs/heads/p4/. Обратите внимание, что будущие операции синхронизации также должны указывать --import-local, чтобы они могли найти ветки p4 в refs/heads.

--max-changes <число>

Импортировать не более число изменений, а не весь диапазон изменений, включённый в данный спецификатор редакции. Типичное использование: указать @all в качестве спецификатора редакции, но затем использовать --max-changes 1000, чтобы импортировать только последние 1000 редакций вместо всей истории редакций.

--changes-block-size <n>

Внутренний размер блока, используемый при преобразовании спецификатора редакции, такого как @all, в список конкретных номеров изменений. Вместо использования одного вызова p4 changes для поиска полного списка изменений для преобразования выполняется последовательность вызовов p4 changes -m, каждый из которых запрашивает один блок изменений указанного размера. Размер блока по умолчанию — 500, что обычно должно быть подходящим.

--keep-path

Сопоставление имён файлов из пути депо p4 в Git по умолчанию включает удаление всего пути депо. С этим параметром полный путь депо p4 сохраняется в Git. Например, путь //depot/main/foo/bar.c при импорте из //depot/main/ становится foo/bar.c. С --keep-path путь Git вместо этого будет depot/main/foo/bar.c.

--use-client-spec

Использовать спецификацию клиента для поиска списка интересующих файлов в p4. См. раздел «СПЕЦИФИКАЦИЯ КЛИЕНТА» ниже.

-/ <путь>

Исключать выбранные пути депо при клонировании или синхронизации.

Параметры клонирования

Эти параметры могут использоваться в начальном clone вместе с описанными выше параметрами sync.

--destination <каталог>

Где создать репозиторий Git. Если не указано, для создания нового каталога используется последний компонент пути депо p4.

--bare

Выполнить голое клонирование. См. git-clone[1].

Параметры отправки

Эти параметры можно использовать для изменения поведения git p4 submit.

--origin <коммит>

Вышестоящее местоположение, из которого идентифицируются коммиты для отправки в p4. По умолчанию это самый последний коммит p4, достижимый из HEAD.

-M

Обнаруживать переименования. См. git-diff[1]. Переименования будут представлены в p4 с использованием явных операций move. Нет соответствующего параметра для обнаружения копий, но есть переменные как для перемещений, так и для копий.

--preserve-user

Изменять автора изменений p4 перед отправкой в p4. Этот параметр требует прав администратора p4.

--export-labels

Экспортировать метки из Git как метки p4. Метки, найденные в Git, применяются к рабочему каталогу perforce.

-n
--dry-run

Показать только то, какие коммиты были бы отправлены в p4; не изменять состояние в Git или p4.

--prepare-p4-only

Применить коммит к рабочей области p4, открывая, добавляя и удаляя файлы в p4, как для обычной операции отправки. Не выполнять финальный "p4 submit", а вместо этого вывести сообщение о том, как отправить вручную или отменить. Этот параметр всегда останавливается после первого (самого старого) коммита. Метки Git не экспортируются в p4.

--shelve

Вместо отправки создать серию отложенных списков изменений. После создания каждой отложенной полки соответствующие файлы отменяются/удаляются. Если у вас есть несколько ожидающих коммитов, будет создано несколько отложенных полок.

--update-shelve СПИСОК_ИЗМЕНЕНИЙ

Обновить существующий отложенный список изменений этим коммитом. Подразумевает --shelve. Повторить для нескольких отложенных списков изменений.

--conflict=(ask|skip|quit)

При применении коммита к p4 могут возникать конфликты. Когда это происходит, поведение по умолчанию ("ask") — запросить, пропустить ли этот коммит и продолжить, или выйти. Этот параметр можно использовать для обхода запроса, заставляя автоматически пропускать конфликтующие коммиты или выходить из попытки применить коммиты без запроса.

--branch <ветка>

После отправки синхронизировать эту именованную ветку вместо p4/master по умолчанию. Дополнительную информацию см. в разделе "Параметры синхронизации" выше.

--commit (<sha1>|<sha1>..<sha1>)

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

--disable-rebase

Отключить автоматическое перемещение после успешной отправки всех коммитов. Также может быть установлено с помощью git-p4.disableRebase.

--disable-p4sync

Отключить автоматическую синхронизацию p4/master из Perforce после отправки коммитов. Подразумевает --disable-rebase. Также может быть установлено с помощью git-p4.disableP4Sync. Синхронизация с origin/master по-прежнему выполняется, если это возможно.

Перехватчики для отправки

p4-pre-submit

Перехватчик p4-pre-submit выполняется, если он существует и является исполняемым. Перехватчик не принимает параметров и ничего не читает из стандартного ввода. Выход из этого сценария с ненулевым статусом предотвращает запуск git-p4 submit. Его можно обойти с помощью параметра командной строки --no-verify.

Один из сценариев использования — запуск модульных тестов в перехватчике.

p4-prepare-changelist

Перехватчик p4-prepare-changelist выполняется сразу после подготовки сообщения списка изменений по умолчанию и перед запуском редактора. Он принимает один параметр — имя файла, содержащего текст списка изменений. Выход из сценария с ненулевым статусом прервёт процесс.

Цель перехватчика — редактировать файл сообщения на месте, и он не подавляется параметром --no-verify. Этот перехватчик вызывается, даже если установлен --prepare-p4-only.

p4-changelist

Перехватчик p4-changelist выполняется после того, как пользователь отредактировал сообщение списка изменений. Его можно обойти с помощью параметра --no-verify. Он принимает один параметр — имя файла, содержащего предлагаемый текст списка изменений. Выход с ненулевым статусом приводит к прерыванию команды.

Перехватчик может редактировать файл списка изменений и использоваться для нормализации текста в соответствии с некоторым стандартным форматом проекта. Он также может использоваться для отказа от отправки после проверки файла сообщения.

p4-post-changelist

Перехватчик p4-post-changelist вызывается после успешной отправки в P4. Он не принимает параметров и предназначен в первую очередь для уведомления и не может повлиять на результат действия git p4 submit.

Параметры перемещения

Эти параметры можно использовать для изменения поведения git p4 rebase.

--import-labels

Импортировать метки p4.

Параметры снятия с полки

--origin

Устанавливает спецификатор ссылки git, относительно которого сравнивается отложенный список изменений P4. По умолчанию p4/master.

СИНТАКСИС ПУТИ DEPOT

Аргумент пути депо p4 для git p4 sync и git p4 clone может быть одним или несколькими разделёнными пробелами путями депо p4 с необязательным спецификатором редакции p4 в конце:

"//depot/my/project"

Импортировать один коммит со всеми файлами в изменении #head в этом дереве.

"//depot/my/project@all"

Импортировать один коммит для каждого изменения в истории этого пути депо.

"//depot/my/project@1,6"

Импортировать только изменения с 1 по 6.

"//depot/proj1@all //depot/proj2@all"

Импортировать все изменения из обоих именованных путей депо в один репозиторий. Включаются только файлы ниже этих каталогов. В Git нет подкаталога для каждого "proj1" и "proj2". При указании более одного пути депо вы должны использовать параметр --destination. Спецификатор редакции должен быть указан одинаково для каждого пути депо. Если в путях депо есть файлы с одинаковыми именами, в Git появляется путь с самой последней обновлённой версией файла.

Полный синтаксис спецификаторов редакций p4 см. в p4 help revisions.

СПЕЦИФИКАЦИЯ КЛИЕНТА

Спецификация клиента p4 поддерживается командой p4 client и содержит, среди прочих полей, View, которая определяет, как депо отображается в репозиторий клиента. Команды clone и sync могут обращаться к спецификации клиента, когда им задан параметр --use-client-spec или когда переменная useClientSpec имеет значение true. После git p4 clone переменная useClientSpec автоматически устанавливается в файле конфигурации репозитория. Это позволяет будущим командам git p4 submit работать правильно; команда submit смотрит только на переменную и не имеет параметра командной строки.

Полный синтаксис для представления p4 описан в p4 help views. git p4 знает только подмножество синтаксиса представления. Он понимает многострочные сопоставления, наложения с +, исключения с - и двойные кавычки вокруг пробелов. Из возможных подстановочных знаков git p4 обрабатывает только …​, и только когда он находится в конце пути. git p4 выдаст предупреждение, если встретит необработанный подстановочный знак.

Существуют ошибки в реализации сопоставлений перекрытий. Если несколько путей депо через наложения отображаются в одно и то же место в репозитории, git p4 может выбрать неправильный. Это трудно решить, не выделяя спецификацию клиента только для git p4.

Имя клиента может быть передано git p4 несколькими способами. Переменная git-p4.client имеет приоритет, если она существует. В противном случае используются обычные механизмы p4 для определения клиента: переменная среды P4CLIENT, файл, на который ссылается P4CONFIG, или локальное имя хоста.

ОБНАРУЖЕНИЕ ВЕТОК

P4 не имеет такого же понятия ветки, как Git. Вместо этого p4 организует своё содержимое в виде дерева каталогов, где по соглашению разные логические ветки находятся в разных местах дерева. Команда p4 branch используется для поддержания сопоставлений между разными областями дерева и указания связанного содержимого. git p4 может использовать эти сопоставления для определения связей между ветками.

Если у вас есть репозиторий, где все интересующие ветки существуют как подкаталоги одного пути депо, вы можете использовать --detect-branches при клонировании или синхронизации, чтобы git p4 автоматически находил подкаталоги в p4 и создавал их как ветки в Git.

Например, если структура репозитория P4 такова:

//depot/main/...
//depot/branch1/...

И «p4 branch -o branch1» показывает строку View, которая выглядит так:

//depot/main/... //depot/branch1/...

Тогда эта команда git p4 clone:

git p4 clone --detect-branches //depot@all

создаёт отдельную ветку в refs/remotes/p4/ для //depot/main, называемую master, и одну для //depot/branch1, называемую depot/branch1.

Однако не обязательно создавать ветки в p4, чтобы использовать их как ветки. Поскольку автоматическое определение связей между ветками затруднено, можно использовать параметр конфигурации Git git-p4.branchList для явного указания связей между ветками. Это список пар «источник:назначение», как простая спецификация ветки p4, где «источник» и «назначение» являются элементами пути в репозитории p4. Приведённый выше пример полагался на наличие ветки p4. Без веток p4 тот же результат будет достигнут с помощью:

git init depot
cd depot
git config git-p4.branchList main:branch1
git p4 clone --detect-branches //depot@all .

ПРОИЗВОДИТЕЛЬНОСТЬ

Механизм fast-import, используемый git p4, создаёт один pack-файл для каждого вызова git p4 sync. Обычно сжатие мусора Git (git-gc[1]) автоматически сжимает их в меньшее количество pack-файлов, но явный вызов git repack -adf может улучшить производительность.

ПЕРЕМЕННЫЕ КОНФИГУРАЦИИ

Следующие параметры конфигурации можно использовать для изменения поведения git p4. Все они находятся в разделе git-p4.

Общие переменные

git-p4.user

Пользователь, указанный в качестве параметра для всех команд p4, с -u <пользователь>. Вместо этого можно использовать переменную среды P4USER.

git-p4.password

Пароль, указанный в качестве параметра для всех команд p4, с -P <пароль>. Вместо этого можно использовать переменную среды P4PASS.

git-p4.port

Порт, указанный в качестве параметра для всех команд p4, с -p <порт>. Вместо этого можно использовать переменную среды P4PORT.

git-p4.host

Хост, указанный в качестве параметра для всех команд p4, с -h <хост>. Вместо этого можно использовать переменную среды P4HOST.

git-p4.client

Клиент, указанный в качестве параметра для всех команд p4, с -c <клиент>, включая спецификацию клиента.

git-p4.retries

Указывает количество повторных попыток выполнения команды p4 (в частности, p4 sync) в случае тайм-аута сети. Значение по умолчанию — 3. Установите значение 0, чтобы отключить повторные попытки, или если ваша версия p4 не поддерживает повторные попытки (до 2012.2).

Переменные клонирования и синхронизации

git-p4.syncFromOrigin

Поскольку импорт коммитов из других репозиториев Git выполняется гораздо быстрее, чем импорт из p4, существует механизм для поиска изменений p4 сначала во внешних репозиториях Git. Если ветки существуют в refs/remote/origin/p4, они будут получены и использованы при синхронизации из p4. Эту переменную можно установить в false, чтобы отключить это поведение.

git-p4.branchUser

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

git-p4.branchList

Список веток для импорта, когда включено обнаружение веток. Каждая запись должна быть парой имён веток, разделённых двоеточием (:). Этот пример объявляет, что обе ветки branchA и branchB были созданы из main:

git config       git-p4.branchList main:branchA
git config --add git-p4.branchList main:branchB
git-p4.ignoredP4Labels

Список меток p4 для игнорирования. Он создаётся автоматически по мере обнаружения неимпортируемых меток.

git-p4.importLabels

Импортировать метки p4 в git, как в --import-labels.

git-p4.labelImportRegexp

Будут импортированы только метки p4, соответствующие этому регулярному выражению. Значение по умолчанию: [a-zA-Z0-9_\-.]+$.

git-p4.useClientSpec

Указывает, что для идентификации интересующих путей депо p4 следует использовать спецификацию клиента p4. Это эквивалентно указанию параметра --use-client-spec. См. раздел "СПЕЦИФИКАЦИЯ КЛИЕНТА" выше. Эта переменная является логической, а не именем клиента p4.

git-p4.pathEncoding

Perforce сохраняет кодировку пути, заданную исходной операционной системой. Git ожидает пути, закодированные в UTF-8. Используйте эту конфигурацию, чтобы сообщить git-p4, какую кодировку Perforce использовал для путей. Эта кодировка используется для перекодирования путей в UTF-8. Например, Perforce в Windows часто использует "cp1252" для кодирования имён путей. Если этот параметр передан в запрос клонирования p4, он сохраняется в результирующем новом репозитории git.

git-p4.metadataDecodingStrategy

Perforce сохраняет кодировку описаний списков изменений и полных имён пользователей, как они были сохранены клиентом в данной ОС. Клиент p4v использует локальную кодировку ОС, поэтому разные пользователи могут в конечном итоге хранить разные описания списков изменений или полные имена пользователей в разных кодировках в одном депо. Git допускает несогласованные/неправильные кодировки в сообщениях коммитов и именах авторов, но ожидает, что они будут указаны в utf-8. git-p4 может использовать три различные стратегии декодирования для обработки неопределённости кодировки в Perforce: passthrough просто передаёт исходные байты из Perforce в git, создавая пригодные для использования, но неправильно закодированные данные, когда данные Perforce закодированы иначе, чем utf-8. strict ожидает, что данные Perforce будут закодированы как utf-8, и не может импортировать, если это не так. fallback пытается интерпретировать данные как utf-8, а в противном случае использует вторичную кодировку — по умолчанию распространённую кодировку Windows cp-1252 — с экранированием байтов верхнего диапазона, если декодирование с резервной кодировкой также не удаётся. В python2 стратегия по умолчанию — passthrough по историческим причинам, а в python3 по умолчанию — fallback. Когда выбран strict и декодирование не удаётся, сообщение об ошибке предложит изменить этот параметр конфигурации в качестве обходного пути. Если этот параметр передан в запрос клонирования p4, он сохраняется в результирующем новом репозитории git.

git-p4.metadataFallbackEncoding

Указывает резервную кодировку для использования при декодировании имён авторов Perforce и описаний списков изменений с использованием стратегии fallback (см. git-p4.metadataDecodingStrategy). Резервная кодировка будет использоваться только тогда, когда декодирование как utf-8 не удаётся. Этот параметр по умолчанию имеет значение cp1252 — распространённая кодировка Windows. Если этот параметр передан в запрос клонирования p4, он сохраняется в результирующем новом репозитории git.

git-p4.largeFileSystem

Указывает систему, которая используется для больших (двоичных) файлов. Пожалуйста, обратите внимание, что системы больших файлов не поддерживают команду git p4 submit. В настоящее время реализован только Git LFS (см. https://git-lfs.github.com/ для получения дополнительной информации). Загрузите и установите расширение командной строки Git LFS, чтобы использовать этот параметр, и настройте его следующим образом:

git config       git-p4.largeFileSystem GitLFS
git-p4.largeFileExtensions

Все файлы, соответствующие расширению файла в списке, будут обрабатываться системой больших файлов. Не добавляйте к расширениям префикс ..

git-p4.largeFileThreshold

Все файлы с несжатым размером, превышающим пороговое значение, будут обрабатываться системой больших файлов. По умолчанию пороговое значение определяется в байтах. Добавьте суффикс k, m или g, чтобы изменить единицу измерения.

git-p4.largeFileCompressedThreshold

Все файлы со сжатым размером, превышающим пороговое значение, будут обрабатываться системой больших файлов. Этот параметр может замедлить процесс клонирования/синхронизации. По умолчанию пороговое значение определяется в байтах. Добавьте суффикс k, m или g, чтобы изменить единицу измерения.

git-p4.largeFilePush

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

git-p4.keepEmptyCommits

Список изменений, содержащий только исключённые файлы, будет импортирован как пустой коммит, если этот логический параметр установлен в true.

git-p4.mapUser

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

git config --add git-p4.mapUser "пользователь_p4 = Имя Фамилия <почта@адрес.com>"

Сопоставление переопределит любую информацию о пользователе из P4. Могут быть определены сопоставления для нескольких пользователей P4.

Переменные отправки

git-p4.detectRenames

Обнаруживать переименования. См. git-diff[1]. Это может быть true, false или оценка, как ожидается git diff -M.

git-p4.detectCopies

Обнаруживать копии. См. git-diff[1]. Это может быть true, false или оценка, как ожидается git diff -C.

git-p4.detectCopiesHarder

Обнаруживать копии более тщательно. См. git-diff[1]. Логическое значение.

git-p4.preserveUser

При отправке изменять автора, чтобы отразить автора Git, независимо от того, кто вызывает git p4 submit.

git-p4.allowMissingP4Users

Когда preserveUser имеет значение true, git p4 обычно завершается критической ошибкой, если не может найти автора в карте пользователей p4. Эта настройка отправляет изменение в любом случае.

git-p4.skipSubmitEdit

Процесс отправки вызывает редактор перед отправкой каждого изменения p4. Если эта настройка имеет значение true, шаг редактирования пропускается.

git-p4.skipSubmitEditCheck

После редактирования сообщения об изменении p4 git p4 проверяет, что описание действительно было изменено, по времени изменения файла. Этот параметр отключает эту проверку.

git-p4.allowSubmit

По умолчанию любая ветка может использоваться в качестве источника для операции git p4 submit. Эта переменная конфигурации, если она установлена, разрешает использовать в качестве источников отправки только именованные ветки. Имена веток должны быть краткими (без "refs/heads/") и должны быть разделены запятыми (",") без пробелов.

git-p4.skipUserNameCheck

Если пользователь, запускающий git p4 submit, не существует в карте пользователей p4, git p4 завершает работу. Этот параметр можно использовать для принудительной отправки независимо от этого.

git-p4.attemptRCSCleanup

Если включено, git p4 submit попытается очистить ключевые слова RCS ($Header$ и т.д.). В противном случае они вызовут конфликты слияния и предотвратят отправку. В настоящее время этот параметр следует считать экспериментальным.

git-p4.exportLabels

Экспортировать метки Git в метки p4, как в --export-labels.

git-p4.labelExportRegexp

Будут экспортированы только метки p4, соответствующие этому регулярному выражению. Значение по умолчанию: [a-zA-Z0-9_\-.]+$.

git-p4.conflict

Указывает поведение при отправке при обнаружении конфликта с p4, как в --conflict. Поведение по умолчанию — ask.

git-p4.disableRebase

Не выполнять перемещение дерева относительно p4/master после отправки.

git-p4.disableP4Sync

Не синхронизировать p4/master с Perforce после отправки. Подразумевает git-p4.disableRebase.

ПОДРОБНОСТИ РЕАЛИЗАЦИИ

  • Наборы изменений из p4 импортируются с использованием Git fast-import.

  • Клонирование или синхронизация не требуют клиента p4; содержимое файлов собирается с помощью p4 print.

  • Отправка требует клиента p4, который находится не в том же месте, что и репозиторий Git. Патчи применяются по одному к этому клиенту p4 и отправляются оттуда.

  • Каждый коммит, импортированный git p4, имеет строку в конце сообщения журнала, указывающую местоположение депо p4 и номер изменения. Эта строка используется последующими операциями git p4 sync, чтобы узнать, какие изменения p4 являются новыми.

GIT

Является частью пакета git[1]