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

НАЗВА

git-fast-export — Експортер даних Git

СИНОПСИС

git fast-export [<options>] | git fast-import

ОПИС

Ця програма виводить вказані ревізії у форматі, придатному для передачі через конвеєр у git fast-import.

Ви можете використовувати його як заміну набору, зрозумілу людині (див. git-bundle[1]), або як формат, який можна редагувати перед передачею до git fast-import для перезапису історії (здатність, на яку покладаються такі інструменти, як git filter-repo).

ОПЦІЇ

--progress=<n>

Вставляти твердження progress <n> об’єктів, щоб їх показував git fast-import під час імпорту.

--signed-tags=(verbatim|warn-verbatim|warn-strip|strip|abort)

Вкажіть, як обробляти підписані теги. Оскільки будь-яке перетворення після експорту (або під час експорту, таке як виключення редакцій) може змінити хеші, що підписуються, підписи можуть стати недійсними.

Якщо вказано параметр abort (що є стандартним значенням), програма завершить роботу при виявленні тегу зі знаком. З опцією strip теги будуть без попередження перетворені на непідписані, з опцією warn-strip — перетворені на непідписані, але з показом попередження, з опцією verbatim — експортовані без попередження, а з опцією warn-verbatim (або warn, застарілим синонімом) — експортовані, але з показом попередження. verbatim та warn-verbatim слід використовувати лише тоді, коли ви впевнені, що ні ви, ні fast-export чи fast-import не виконуватимуть жодних перетворень, які впливають на теги чи будь-які коміти в їхній історії, або якщо вам байдуже, що отриманий тег матиме недійсний підпис.

--signed-commits=(verbatim|warn-verbatim|warn-strip|strip|abort)

Вкажіть, як обробляти підписані коміти. Поводиться точно так само, як --signed-tags, але для комітів. Стандартне значення — strip, що так само, як і попередні версії цієї команди без цієї опції.

Під час експорту підпис починається з:

gpgsig <git-hash-algo> <signature-format>

де <git-hash-algo> — це хеш обʼєкта Git, тобто "sha1" або "sha256", а <signature-format> — це тип підпису, тобто "openpgp", "x509", "ssh" або "unknown".

Наприклад, підпис OpenPGP у коміті SHA-1 починається з gpgsig sha1 openpgp, тоді як підпис SSH у коміті SHA-256 починається з gpgsig sha256 ssh.

Хоча всі підписи коміта експортуються, імпортер може прийняти лише деякі з них. Наприклад, git-fast-import[1] наразі зберігає щонайбільше один підпис на алгоритм хешування Git у кожному коміті.

Note
 Це дуже експериментальна можливість, і формат потоку даних може змінитися в майбутньому без гарантій сумісності.
--tag-of-filtered-object=(abort|drop|rewrite)

Вкажіть, як поводитися з тегами, обʼєкти яких було відфільтровано. Оскільки версії та файли для експорту можна обмежити за шляхом, обʼєкти з тегами можуть бути повністю відфільтровані.

Якщо вказано abort (що є стандартним значенням), програма завершить роботу при виявленні такого тегу. При виборі drop такі теги будуть пропущені у вихідних даних. При виборі rewrite, якщо об’єкт із тегом є комітом, тег буде переписано так, щоб він позначав попередній коміт (за допомогою перезапису батьківського коміту; див. git-rev-list[1]).

-M
-C

Виконайте виявлення переміщення та/або копіювання, як описано на сторінці довідки git-diff[1], та використовуйте його для створення команд перейменування та копіювання у вихідному дампі.

Зверніть увагу, що попередні версії цієї команди не скаржилися та видавали неправильні результати, якщо ви вказали ці параметри.

--export-marks=<file>

Згенерує внутрішню таблицю позначок у <файл> після завершення. Позначки записуються по одній на рядок як :markid SHA-1. Згенеруються лише позначки для редакцій; позначки для блобів ігноруються. Бекенди можуть використовувати цей файл для перевірки імпорту після його завершення або для збереження таблиці позначок під час інкрементних запусків. Оскільки <файл> відкривається та обрізається лише після завершення, той самий шлях також можна безпечно надати --import-marks. Файл не буде записано, якщо не було позначено/експортовано новий обʼєкт.

--import-marks=<file>

Перед обробкою будь-яких вхідних даних завантажте позначки, зазначені у <файлі>. Вхідний файл має існувати, бути читабельним та використовувати той самий формат, що й --export-marks.

--mark-tags

Окрім позначення блобів та комітів ідентифікаторами міток, також додавайте мітки до тегів. Це корисно в поєднанні з --export-marks та --import-marks, а також корисно (і необхідно) для експорту вкладених тегів. Це не зашкодить іншим випадкам і буде використовуватися зазвичай, але багато фронтендів швидкого імпорту не готові приймати теги з ідентифікаторами міток.

Будь-які коміти (або теги), які вже були позначені, не будуть експортовані знову. Якщо бекенд використовує подібний файл --import-marks, це дозволяє здійснювати поступовий двонаправлений експорт репозиторію, зберігаючи позначки однаковими протягом усіх запусків.

--fake-missing-tagger

Деякі старі репозиторії мають теги без теґера. Протокол швидкого імпорту був досить суворим щодо цього і не дозволяв цього. Тож створіть фальшивий теґер, щоб мати змогу швидко імпортувати вивід.

--use-done-feature

Почніть потік із блоку feature done і завершіть його командою done.

--no-data

Пропускати вивід блоб-обʼєктів і натомість звертатися до блоб-обʼєктів через їхній оригінальний хеш SHA-1. Це корисно під час перезапису структури тек або історії репозиторію без зміни вмісту окремих файлів. Зверніть увагу, що отриманий потік може використовуватися лише репозиторієм, який вже містить необхідні обʼєкти.

--full-tree

Ця опція призведе до того, що fast-export видасть директиву "deleteall" для кожного коміту, а потім повний список усіх файлів у коміті (на відміну від простого переліку файлів, які відрізняються від першого батьківського коміту).

--anonymize

Анонімізуйте вміст репозиторію, зберігаючи при цьому форму історії та збереженого дерева. Див. розділ «АНОНІМІЗАЦІЯ» нижче.

--anonymize-map=<from>[:<to>]

Перетворити токен <from> на <to> в анонімізованому виводі. Якщо <to> пропущено, зіставити <from> з самим собою (тобто не анонімізувати його). Див. розділ про АНОНІМІЗАЦІЮ нижче.

--reference-excluded-parents

Зазвичай, виконання команди типу git fast-export master~5..master не включатиме коміт master~5 і призведе до того, що master~4 більше не матиме master~5 як батьківського (хоча і старий master~4, і новий master~4 матимуть однакові файли). Використовуйте --reference-excluded-parents, щоб потік посилався на коміти у виключеному діапазоні історії за їхнім sha1sum. Зверніть увагу, що отриманий потік може використовуватися лише репозиторієм, який вже містить необхідні батьківські коміти.

--show-original-ids

Додайте додаткову директиву до виводу для комітів та блобів, original-oid <SHA1SUM>. Хоча такі директиви, ймовірно, будуть ігноруватися імпортерами, такими як git-fast-import, вона може бути корисною для проміжних фільтрів (наприклад, для перезапису повідомлень комітів, які посилаються на старіші коміти, або для видалення блобів за ідентифікатором).

--reencode=(yes|no|abort)

Вкажіть, як поводитися з заголовком encoding в об’єктах коміту. Якщо вказано abort (що є стандартним значенням) програма завершить роботу при виявленні такого обʼєкта коміту. Якщо вказано yes, повідомлення коміту буде перекодовано в UTF-8. Якщо вказано no, оригінальне кодування буде збережено.

--refspec

Застосувати вказану специфікацію посилання до кожного експортованого посилання. Можна вказати кілька таких посилань.

[<git-rev-list-args>…​]

Список аргументів, прийнятних для git rev-parse та git rev-list, що визначає конкретні обʼєкти та посилання для експорту. Наприклад, master~10..master призводить до експорту поточного посилання master разом з усіма обʼєктами, доданими з моменту його 10-го коміту предка, та (якщо не вказано опцію --reference-excluded-parents) усіма файлами, спільними для master~9 та master~10.

ПРИКЛАДИ

$ git fast-export --all | (cd /empty/repository && git fast-import)

Це експортує весь репозиторій та імпортує його до наявного порожнього репозиторію. За винятком перекодування комітів, які не в UTF-8, це буде дзеркало один до одного.

$ git fast-export master~5..master |
	sed "s|refs/heads/master|refs/heads/other|" |
	git fast-import

Це створює нову гілку з назвою other з master~5..master (тобто, якщо master має лінійну історію, вона візьме останні 5 комітів).

Зверніть увагу, що це передбачає, що жоден з блобів та повідомлень про коміти, на які посилається цей діапазон редакцій, не містить рядка refs/heads/master.

АНОНІМІЗАЦІЯ

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

З цією опцією git замінить усі посилання, шляхи, вміст блобів, повідомлення комітів та тегів, імена та адреси електронної пошти у виводі анонімізованими даними. Два екземпляри одного й того ж рядка будуть еквівалентно замінені (наприклад, два коміти з однаковим автором матимуть однакового анонімізованого автора у виводі, але не матимуть жодної схожості з оригінальним рядком автора). Звʼязок між комітами, гілками та тегами зберігається, як і відбитки часу комітів (але повідомлення комітів та посилання не мають жодної схожості з оригіналами). Відносний склад дерева зберігається (наприклад, якщо у вас є кореневе дерево з 10 файлами та 3 деревами, то й вивід буде таким самим), але їхні імена та вміст файлів будуть замінені.

Якщо ви вважаєте, що знайшли помилку в git, можете почати з експорту анонімного потоку всього репозиторію:

$ git fast-export --anonymize --all >anon-stream

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

$ git init anon-repo
$ cd anon-repo
$ git fast-import <../anon-stream
$ ... test your bug ...

Якщо анонімізований репозиторій показує помилку, можливо, варто поділитися anon-stream разом зі звичайним звітом про помилку. Зверніть увагу, що анонімізований потік дуже добре стискається, тому рекомендується його стискання за допомогою gzip-архіву. Якщо ви хочете перевірити потік, щоб переконатися, що він не містить жодних особистих даних, ви можете переглянути його безпосередньо перед надсиланням. Ви також можете спробувати:

$ perl -pe 's/\d+/X/g' <anon-stream | sort -u | less

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

Відтворення деяких помилок може вимагати посилання на певні коміти або шляхи, що стає складним після анонімізації посилань та шляхів. Ви можете попросити залишити певний токен як є або зіставити його з новим значенням. Наприклад, якщо у вас є помилка, яка відтворюється за допомогою git rev-list sensitive -- secret.c, ви можете виконати:

$ git fast-export --anonymize --all \
      --anonymize-map=sensitive:foo \
      --anonymize-map=secret.c:bar.c \
      >stream

Після імпорту потоку ви можете виконати git rev-list foo -- bar.c в анонімізованому репозиторії.

Зверніть увагу, що шляхи та посилання розділені на токени на межах, що містять косі риски. Наведена вище команда анонімізує subdir/secret.c як щось на кшталт path123/bar.c; тоді ви можете пошукати bar.c в анонімізованому репозиторії, щоб визначити остаточний шлях.

Щоб спростити посилання на кінцевий шлях, ви можете зіставити кожен компонент шляху; тому, якщо ви також анонімізуєте subdir як publicdir, то кінцевий шлях буде publicdir/bar.c.

ОБМЕЖЕННЯ

Оскільки git fast-import не може позначати дерева тегами, ви не зможете повністю експортувати репозиторій linux.git, оскільки він містить тег, що посилається на дерево, а не на коміт.

ДИВ. ТАКОЖ

git-fast-import[1]

GIT

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