українська мова ▾ Topics ▾ Latest version ▾ git-p4 last updated in 2.52.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

КОМАНДИ

Clone

Зазвичай, 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

Sync

Оскільки розробка в репозиторії 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

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

Якщо репозиторій Git містить гілки refs/remotes/origin/p4, під час виконання команди git p4 sync вони будуть завантажені та перевірені в першу чергу. Оскільки імпорт безпосередньо з p4 відбувається значно повільніше, ніж отримання змін із віддаленого репозиторію Git, це може бути корисно в середовищі, де працюють кілька розробників.

Якщо є кілька гілок, виконання команди git p4 sync автоматично використовуватиме алгоритм «ВИЯВЛЕННЯ ГІЛОК», щоб спробувати розділити нові зміни в правильній гілці. Це можна перевизначити за допомогою опції --branch, щоб вказати лише одну гілку для оновлення.

Rebase

Поширена схема роботи полягає в отриманні останніх змін з депо p4 та обʼєднанні їх з локальними незафіксованими змінами. Часто репозиторій p4 є кінцевим місцем зберігання всього коду, тому робочий процес перебазування має сенс. Ця команда виконує git p4 sync, а потім git rebase, щоб перемістити локальні коміти поверх оновлених змін p4.

$ git p4 rebase

Submit

Надсилання змін з репозиторію 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

Unshelve

Команда 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 на наявність міток, повʼязаних зі шляхами depot, та додавайте їх як теги в 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>

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

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

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

--destination <directory>

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

--bare

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

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

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

--origin <commit>

Місце розташування upstream, з якого визначаються коміти для надсилання до 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

Замість надсилання створіть серію відкладених списків змін. Після створення кожної полиці (shelve) відповідні файли скасовуються/видаляються. Якщо у вас є кілька комітів, що очікують на розгляд, буде створено кілька полиць.

--update-shelve CHANGELIST

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

--conflict=(ask|skip|quit)

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

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

Варіанти unshelve

--origin

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

СИНТАКСИС ШЛЯХУ DEPOT

Аргумент шляху до p4 depot для git p4 sync та git p4 clone може бути одним або кількома шляхами до p4 depot, розділеними пробілами, з необовʼязковим специфікатором ревізії p4 в кінці:

"//depot/my/project"

Імпортуйте один коміт з усіма файлами зі зміни #head в цьому дереві.

"//depot/my/project@all"

Імпортуйте один коміт для кожної зміни в історії цього шляху depot.

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

Імпортувати лише зміни з 1 по 6.

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

Імпортуйте всі зміни з обох вказаних шляхів сховища в одне сховище. Включаються лише файли в цих теках. У Git немає теки для кожного "proj1" та "proj2". Ви повинні використовувати опцію --destination, якщо вказуєте більше одного шляху сховища. Специфікатор ревізії має бути вказаний однаково для кожного шляху сховища. Якщо в шляхах сховища є файли з однаковою назвою, шлях з останньою оновленою версією файлу відображається в Git.

Див. розділ «довідка щодо версій p4» для повного синтаксису специфікаторів версій p4.

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

Специфікація клієнта p4 підтримується командою p4 client і містить, серед інших полів, View, який визначає, як depot відображається в клієнтському репозиторії. Команди 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 поскаржиться, якщо зустріне необроблений шаблон підстановки.

У реалізації співвіднесення перекриттів є помилки. Якщо кілька шляхів до depot через накладення співвідносяться з одним і тим самим місцем у репозиторії, команда git p4 може вибрати неправильний шлях. Цю проблему важко вирішити без створення окремої специфікації клієнта саме для git p4.

Імʼя клієнта можна надати git p4 кількома способами. Змінна git-p4.client має пріоритет, якщо вона існує. В іншому випадку використовуються звичайні механізми p4 для визначення клієнта: змінна середовища P4CLIENT, файл, на який посилається P4CONFIG, або імʼя локального хосту.

ВИЯВЛЕННЯ ГІЛОК

P4 не має такої ж концепції гілки, як Git. Натомість p4 організовує свій вміст як дерево тек, де за домовленістю різні логічні гілки знаходяться в різних місцях дерева. Команда p4 branch використовується для підтримки зіставлень між різними областями дерева та позначення повʼязаного вмісту. git p4 може використовувати ці зіставлення для визначення звʼязків гілок.

Якщо у вас є репозиторій, де всі гілки, що вас цікавлять, існують як теки одного шляху depot, ви можете використовувати --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 має використовуватися для ідентифікації шляхів depot 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 — з екрануванням байтів верхнього діапазону, якщо декодування з використанням резервного кодування також не вдається. У Python 2 стандартною стратегією є passthrough з історичних причин, а в Python 3 — 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. Стандартна поведінка  — 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, має рядок в кінці повідомлення журналу, який вказує місце знаходження depot p4 та номер зміни. Цей рядок використовується пізнішими операціями git p4 sync, щоб дізнатися, які зміни p4 є новими.

GIT

Частина набору git[1]