українська мова ▾ 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)

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

При запиті на «переривання» (що є налаштуванням за замовчуванням) ця програма завершить роботу, якщо зіткнеться з підписаним тегом. З командою «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)

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

При запиті на «переривання» (що є значенням за замовчуванням) ця програма завершить роботу, якщо зіткнеться з таким тегом. З опцією «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

Запустіть потік зі строфи «функція виконана» та завершіть його командою «готово».

--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 в об’єктах комітів. При запиті на «переривання» (що є значенням за замовчуванням) ця програма завершить роботу, зіткнувшись з таким об’єктом коміту. Якщо встановлено значення «так», повідомлення коміту буде перекодовано в UTF-8. Якщо встановлено значення «ні», оригінальне кодування буде збережено.

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

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