українська мова ▾ Topics ▾ Latest version ▾ git-p4 last updated in 2.50.0

НАЗВА

git-p4 - Імпорт з та надсилання до репозиторіїв Perforce

СИНОПСИС

git p4 clone [<sync-options>] [<clone-options>] <p4-depot-path>…​
git p4 sync [<sync-options>] [<p4-depot-path>…​]
git p4 rebase
git p4 submit [<submit-options>] [<master-branch-name>]

ОПИС

Ця команда надає спосіб взаємодії з репозиторіями p4 за допомогою Git.

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

ПРИКЛАДИ

  • Клонування репозиторію:

    $ git p4 clone //depot/path/project

  • Виконайте певну роботу у щойно створеному репозиторії Git:

    $ cd project
$ vi foo.h
$ git commit -a -m "edited foo.h"

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

    $ git p4 rebase

  • Надішліть ваші коміти назад до p4:

    $ git p4 submit

КОМАНДИ

Клон

Зазвичай, «git p4 clone» використовується для створення нового каталогу Git з існуючого репозиторію p4:

$ git p4 clone //depot/path/project

Це:

  1. Створює порожній репозиторій Git у підкаталозі з назвою «project».

  2. Імпортує повний вміст головної ревізії з заданого шляху депо p4 в один коміт у гілці Git refs/remotes/p4/master.

  3. Створює локальну гілку «master» з цього віддаленого комп’ютера та перевіряє її.

Щоб відтворити всю історію p4 у Git, використовуйте модифікатор @all у шляху depot:

$ git p4 clone //depot/path/project@all

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

Оскільки розробка в репозиторії p4 продовжується, ці зміни можна буде включити до репозиторію Git за допомогою:

$ git p4 sync

Ця команда знаходить нові зміни в p4 та імпортує їх під час комітів Git.

Репозиторії P4 також можна додати до існуючого репозиторію Git за допомогою git p4 sync:

$ mkdir repo-git
$ cd repo-git
$ git init
$ git p4 sync //path/in/your/perforce/depot

Це імпортує вказаний депо до refs/remotes/p4/master у існуючому репозиторії Git. Опцію --branch можна використовувати для визначення іншої гілки, яка буде використовуватися для вмісту p4.

Якщо репозиторій Git містить гілки refs/remotes/origin/p4, вони будуть отримані та консультовані першими під час синхронізації git p4. Оскільки імпорт безпосередньо з 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 topicbranch

Щоб вказати один коміт або діапазон комітів, використовуйте:

$ 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

Зняти з полиці

Команда Unshelving візьме відкладений список змін P4 та створить еквівалентний коміт git у гілці refs/remotes/p4-unshelved/<список змін>.

Коміт git створюється відносно поточної ревізії оригіналу (за замовчуванням HEAD). Батьківський коміт створюється на основі оригіналу, а потім на його основі створюється коміт unshelve.

Початкову версію можна змінити за допомогою опції "--origin".

Якщо цільова гілка в refs/remotes/p4-unshelved вже існує, стара буде перейменована.

$ git p4 sync
$ git p4 unshelve 12345
$ git show p4-unshelved/12345
<submit more changes via p4 to the same files>
$ git p4 unshelve 12345
<refuses to unshelve until git is in sync with p4 again>

ОПЦІЇ

Загальні параметри

Усі команди, крім clone, приймають ці опції.

--git-dir <dir>

Встановіть змінну середовища GIT_DIR. Див. git[1].

-v
--verbose

Надайте більше інформації про прогрес.

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

Ці опції можна використовувати як у початковому «клонуванні», так і в наступних операціях «синхронізації».

--branch <ref>

Імпортувати зміни до <ref> замість refs/remotes/p4/master. Якщо <ref> починається з refs/, він використовується як є. В іншому випадку, якщо він не починається з p4/, додається цей префікс.

За замовчуванням <ref>, що не починається з refs/, трактується як назва гілки віддаленого відстеження (в refs/remotes/). Цю поведінку можна змінити за допомогою опції --import-local.

Значення <ref> за замовчуванням — «master».

У цьому прикладі імпортується новий віддалений "p4/proj2" до існуючого репозиторію Git:

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

Використайте алгоритм виявлення розгалужень, щоб знайти нові шляхи в p4. Він описаний нижче в розділі "ВИЯВЛЕННЯ РОЗГАЛЮВАНЬ".

--changesfile <file>

Імпортуйте саме ті зміни p4, що вказані у file, по одній на рядок. Зазвичай 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 <n>

Імпортувати не більше n змін, а не весь діапазон змін, включених у заданий специфікатор редакції. Типовим використанням було б використання @all як специфікатора редакції, а потім використання --max-changes 1000 для імпорту лише останніх 1000 редакцій, а не всієї історії редакцій.

--changes-block-size <n>

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

--keep-path

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

--use-client-spec

Використайте специфікацію клієнта, щоб знайти список цікавих файлів у p4. Див. розділ "СПЕЦИФІКАЦІЯ КЛІЄНТА" нижче.

-/ <path>

Виключити вибрані шляхи депо під час клонування або синхронізації.

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

Ці опції можна використовувати в початковому «клоні» разом з опціями «синхронізації», описаними вище.

--destination <directory>

Де створити репозиторій Git. Якщо не вказано, для створення нового каталогу використовується останній компонент у шляху p4 depot.

--bare

Виконайте голий клон. Див. git-clone[1].

Параметри надсилання

Ці опції можна використовувати для зміни поведінки «git p4 submit».

--origin <commit>

Розташування у верхній течії, з якого ідентифікуються коміти для надсилання до p4. За замовчуванням це найновіший коміт p4, доступний з HEAD.

-M

Виявлення перейменувань. Див. git-diff[1]. Перейменування будуть представлені в p4 за допомогою явних операцій «переміщення». Немає відповідної опції для виявлення копій, але є змінні як для переміщень, так і для копій.

--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 CHANGELIST

Оновіть існуючий список відкладених змін за допомогою цього коміту. Має на увазі --shelve. Повторіть для кількох відкладених списків змін.

--conflict=(ask|skip|quit)

Конфлікти можуть виникати під час застосування коміту до p4. Коли це трапляється, поведінка за замовчуванням ("запитувати") полягає в тому, щоб запитати, чи пропустити цей коміт і продовжити, чи вийти. Цей параметр можна використовувати для обходу запиту, що призведе до автоматичного пропускання конфліктуючих комітів, або для припинення спроб застосування комітів без запиту.

--branch <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.

Параметри перебазування

Ці опції можна використовувати для зміни поведінки «git p4 rebase».

--import-labels

Імпортувати мітки p4.

Варіанти зняти з полиці

--origin

Встановлює специфікацію посилань git, з якою порівнюється відкладений список змін P4. За замовчуванням використовується p4/master.

СИНТАКСИС ШЛЯХУ ДО ДЕПО

Аргумент шляху до p4 depot для git p4 sync та git p4 clone може бути одним або кількома шляхами до p4 depot, розділеними пробілами, з необов’язковим специфікатором ревізії 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.

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

Специфікація клієнта 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 .

ПРОДУКТИВНІСТЬ

Механізм швидкого імпорту, який використовується «git p4», створює один пакетний файл для кожного виклику «git p4 sync». Зазвичай, стиснення сміття Git (git-gc[1]) автоматично стискає їх до меншої кількості пакетних файлів, але явний виклик «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

Список гілок, які потрібно імпортувати, коли ввімкнено виявлення гілок. Кожен запис має бути парою назв гілок, розділених двокрапкою (:). У цьому прикладі зазначається, що як гілкаA, так і гілкаB були створені з 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 та описів списків змін за допомогою стратегії «резервного кодування» (див. 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 "p4user = First Last <mail@address.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. Поведінка за замовчуванням — «запитувати».

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]