git-filter-branch - Інтернет у хмарі

ПРОГРАМА:

ІМ'Я

git-filter-branch - Переписати гілки

СИНТАКСИС

мерзотник фільтр-гілка [--env-filter ] [--дерево-фільтр ]
[--індекс-фільтр ] [--батьківський-фільтр ]
[--msg-filter ] [--фільтр-фіксація ]
[--тег-ім'я-фільтр ] [--підкаталог-фільтр ]
[--prune-empty]
[--оригінал ] [-d ] [-f | --сила]
[--] [ ...]

ОПИС

Дозволяє переписувати історію версій Git, переписуючи гілки, згадані в
options>, застосовуючи спеціальні фільтри до кожної версії. Ці фільтри можуть змінювати кожне дерево
(наприклад, видалення файлу або запуск перезапису perl для всіх файлів) або інформацію про кожен
здійснити. В іншому випадку вся інформація (включаючи початковий час фіксації або інформацію про злиття)
буде збережено.

Команда лише перепише позитивний посилання, згадані в командному рядку (наприклад, якщо ви
проходити а..б, лише b буде переписано). Якщо ви не вкажете жодних фільтрів, коміти будуть
повторно внесено без будь-яких змін, які зазвичай не мають жодного ефекту. Тим не менш, це
може бути корисним у майбутньому для компенсації деяких помилок Git чи такого, отже, такого
використання дозволено.

ПРИМІТКА: Ця команда враховує файл .git/info/grafts і посилання в просторі імен refs/replace/.
Якщо у вас є якісь графти або посилання на заміну визначені, виконання цієї команди створить їх
постійний.

УВАГА! Переписана історія матиме різні імена об’єктів для всіх об’єктів і
не буде збігатися з вихідною гілкою. Ви не зможете легко штовхнути і
розподіліть переписану гілку поверх оригінальної гілки. Будь ласка, не використовуйте це
команду, якщо ви не знаєте всі наслідки, і уникайте її використання в будь-якому випадку, якщо це проста
Одного коміту буде достатньо, щоб вирішити вашу проблему. (Дивіться розділ «ВІДНОВЛЕННЯ З ВЕРХНЯ
REBASE" розділ в git-rebase(1) для додаткової інформації про переписування опубліковано
історія.)

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

Зауважте, що оскільки ця операція дуже дорога введення-виводу, може бути гарною ідеєю перенаправити
тимчасовий каталог поза диском з -d варіант, наприклад, на tmpfs. Повідомляється про прискорення
дуже помітно.

фільтри
Фільтри застосовуються в порядку, наведеному нижче. The аргумент завжди
оцінюється в контексті оболонки за допомогою евал команда (за помітним винятком
з технічних причин). До цього змінна середовища $GIT_COMMIT
буде встановлено таким чином, щоб він містив ідентифікатор коміту, що переписується. Також, GIT_AUTHOR_NAME,
GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL та
GIT_COMMITTER_DATE беруться з поточного коміту та експортуються в середовище в
щоб вплинути на ідентифікатори автора та фіксатора замінного коміту, створеного
git-дерево-комітів(1) після запуску фільтрів.

Якщо якась оцінка повертає ненульовий статус виходу, вся операція буде
перервано.

A карта доступна функція, яка приймає аргумент "початковий ідентифікатор sha1" і виводить a
"перезаписаний ідентифікатор sha1", якщо коміт уже переписаний, і "оригінальний ідентифікатор sha1"
інакше; в карта функція може повертати кілька ідентифікаторів в окремих рядках, якщо ваш фільтр фіксації
випущено кілька комітів.

ВАРІАНТИ

--env-фільтр
Цей фільтр можна використовувати, якщо вам потрібно лише змінити середовище, в якому виконується фіксація
буде виконано. Зокрема, ви можете переписати автора/комітера
Змінні середовища name/email/time (див git-дерево-комітів(1) для деталей). Не
забудьте повторно експортувати змінні.

--дерево-фільтр
Це фільтр для перезапису дерева та його вмісту. Аргумент оцінюється
в оболонці з робочим каталогом, встановленим у корені перевіреного дерева. Новий
дерево потім використовується як є (нові файли додаються автоматично, зниклі файли автоматично видаляються
- ні файли .gitignore, ні будь-які інші правила ігнорування МИЛИ БУДЬ ЕФЕКТ!).

--індексний фільтр
Це фільтр для перезапису індексу. Він подібний до фільтра дерева, але є
не перевіряйте дерево, що робить його набагато швидшим. Часто використовується з git rm
--cached --ignore-unmatch ..., див. ПРИКЛАДИ нижче. Про волохаті випадки див git-оновлення-
індекс(1).

--батьківський фільтр
Це фільтр для перезапису батьківського списку коміту. Його отримає батько
string на stdin і виведе новий батьківський рядок на stdout. Батьківський рядок є
у форматі, описаному в git-дерево-комітів(1): порожній для початкової фіксації, "-p
parent" для звичайного коміту і "-p parent1 -p parent2 -p parent3 ..." для злиття
вчинити.

--msg-filter
Це фільтр для перезапису повідомлень фіксації. Аргумент оцінюється в
оболонка з вихідним повідомленням про фіксацію на стандартному вводі; використовується його стандартний вихід
як нове повідомлення про фіксацію.

--фіксувати-фільтр
Це фільтр для виконання фіксації. Якщо вказано цей фільтр, він буде
називається замість the мерзотник дерево комітів команда з аргументами виду "
[(-с )...]" та повідомлення журналу на stdin. Очікується ідентифікатор фіксації
на stdout.

Як спеціальне розширення, фільтр фіксації може видавати кілька ідентифікаторів фіксації; в такому разі,
переписані діти вихідного коміту матимуть усіх їх як батьків.

Ви можете використовувати карта функція зручності в цьому фільтрі та інші зручності
функції також. Наприклад, дзвонити skip_commit "$@" залишить поза межами течії
commit (але не його зміни! Якщо ви хочете цього, використовуйте мерзотник ребаза замість цього).

Ви також можете використовувати git_commit_non_empty_tree "$@" замість git commit-tree "$@", якщо
ви не хочете зберігати коміти з одним батьком, і це не вносить ніяких змін до
дерево.

--filter-ім’я тегу
Це фільтр для перезапису імен тегів. Після проходження він буде викликаний для кожного
тег ref, який вказує на переписаний об’єкт (або на об’єкт тега, який вказує на a
переписаний об’єкт). Початкове ім'я тегу передається через стандартний вхід, а новий тег
ім'я очікується на стандартному виводі.

Оригінальні теги не видаляються, але можуть бути перезаписані; використовувати "--tag-name-filter cat"
щоб просто оновити теги. У цьому випадку будьте дуже обережні та переконайтеся, що у вас є
резервні копії старих тегів на випадок, якщо перетворення завершується.

Підтримується майже правильне перезапис об’єктів тегів. Якщо тег містить повідомлення
буде створено новий об’єкт тега з тим самим повідомленням, автором і
мітка часу. Якщо до тега додається підпис, підпис буде видалено. це є
за визначенням неможливо зберегти підписи. Причина, по якій це "майже" правильно,
тому, що в ідеалі, якщо тег не змінився (вказує на той самий об’єкт, має те саме
ім'я тощо) він повинен зберігати будь-який підпис. Це не так, підписи будуть
завжди видаляти, покупець остерігайтеся. Також немає підтримки зміни автора або
мітка часу (або повідомлення тегу, якщо на те пішло). Будуть теги, які вказують на інші теги
переписано, щоб вказати на базовий коміт.

--підкаталог-фільтр
Дивіться лише історію, яка стосується даного підкаталогу. Результат буде містити
цей каталог (і тільки це) як корінь проекту. Має на увазі розділ під назвою «Remap
до предка».

--чернослив-порожній
Якісь фільтри створять порожні коміти, які залишають дерево недоторканим. Це
switch дозволяє git-filter-branch ігнорувати такі коміти. Хоча, лише цей перемикач
застосовується до комітів, які мають одного і лише одного батьківського елемента, тому він зберігатиме злиття
точки. Крім того, ця опція не сумісна з використанням --фіксувати-фільтр, Хоча
вам просто потрібно скористатися функцією git_commit_non_empty_tree "$@" замість git
commit-tree "$@" ідіома у вашому фільтрі фіксації, щоб це сталося.

--оригінал
Використовуйте цю опцію, щоб встановити простір імен, у якому будуть зберігатися оригінальні коміти. The
значення за замовчуванням посилання/оригінал.

-d
Використовуйте цей параметр, щоб встановити шлях до тимчасового каталогу, який використовується для перезапису. Коли
застосовуючи фільтр дерева, команді потрібно тимчасово перевірити дерево для деяких
каталог, який може зайняти значний простір у разі великих проектів. За замовчуванням
він робить це в .git-rewrite/ каталогу, але ви можете змінити цей вибір за допомогою цього
параметр.

-f, --сила
мерзотник фільтр-гілка відмовляється запускати з існуючого тимчасового каталогу або коли там
вже refs починаються з посилання/оригінал/, якщо не примусово.

...
Аргументи за мерзотник рев-лист. Усі позитивні посилання, включені в ці параметри, переписуються.
Ви також можете вказати такі параметри, як --все, але ви повинні використовувати -- відокремити їх від
мерзотник фільтр-гілка варіанти. Має на увазі розділ під назвою «Перепризначення до предка».

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

ПРИКЛАДИ

Припустимо, ви хочете видалити файл (містить конфіденційну інформацію або авторські права
порушення) з усіх вчинення:

git filter-branch --tree-filter 'rm filename' ГОЛОВКА

Однак, якщо файл відсутній у дереві деякого коміту, буде просте ім’я файлу rm
помилка для цього дерева та фіксація. Таким чином, ви можете замість цього використовувати rm -f filename як файл
сценарій

Використання --index-filter with мерзотник rm дає значно швидшу версію. Як і з використанням rm
filename, git rm --cached filename не вдасться, якщо файл відсутній у дереві
здійснити. Якщо ви хочете «повністю забути» файл, не має значення, коли він увійшов
історію, тому ми також додаємо --ignore-unmatch:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' ГОЛОВКА

Тепер ви отримаєте переписану історію, збережену в HEAD.

Переписати репозиторій, щоб виглядав так, ніби foodir/ був коренем його проекту, і відкинути все
інша історія:

git filter-branch --subdirectory-filter foodir -- --all

Таким чином, ви можете, наприклад, перетворити підкаталог бібліотеки на власне сховище. Зверніть увагу на --
що розділяє фільтр-гілка параметри з параметрів ревізії та --all для перезапису всіх
гілки та теги.

Щоб встановити фіксацію (який зазвичай знаходиться на вершині іншої історії) як батьківський
поточний початковий коміт, щоб вставити іншу історію за поточну історію:

git filter-branch --parent-filter 'sed "s/^\$/-p /"' ГОЛОВА

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

git filter-branch --parent-filter \
'test $GIT_COMMIT = && echo "-стор " || ГОЛОВА кота

або ще простіше:

echo "$commit-id $graft-id" >> .git/info/grafts
git filter-branch $graft-id..HEAD

Щоб видалити коміти автора "Дарла МакБрайба" з історії:

git filter-branch --commit-filter '
якщо [ "$GIT_AUTHOR_NAME" = "Дарл МакБрайб" ];
потім
skip_commit "$@";
ще
git commit-tree "$@";
fi' ГОЛОВА

Функція skip_commit визначається так:

skip_commit()
{
зміна;
while [ -n "$1" ];
do
зміна;
карта «$1»;
зміна;
виконано;
}

Магія shift спочатку викидає ідентифікатор дерева, а потім параметри -p. Зауважте, що це
правильно обробляє злиття! У випадку, якщо Дарл здійснив злиття між P1 і P2, це буде
поширюється належним чином, і всі дочірні елементи злиття стануть комітами злиття з P1,P2 як
їхні батьки замість коміту злиття.

ПРИМІТКА зміни, внесені комітами, і які не скасовуються в подальшому
фіксує, все одно буде в переписаній гілці. Якщо хочеш викинути зміни разом
з комітами ви повинні використовувати інтерактивний режим мерзотник ребаза.

Ви можете переписати повідомлення журналу фіксації за допомогою --msg-filter. Наприклад, мерзотник svn-id
рядків у сховищі, створеному мерзотник svn можна видалити таким чином:

git filter-branch --msg-filter '
sed -e "/^git-svn-id:/d"
'

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

git filter-branch --msg-filter '
кіт &&
echo «Acked-by: Bugs Bunny[захищено електронною поштою]>"
' ГОЛОВКА~10..ГОЛОВКА

Параметр --env-filter можна використовувати для зміни ідентифікатора фіксатора та/або автора. Для
наприклад, якщо ви дізналися, що ваші коміти мають неправильну ідентифікацію через неправильну конфігурацію
user.email, ви можете внести виправлення перед публікацією проекту, наприклад:

git filter-branch --env-filter '
якщо тест "$GIT_AUTHOR_EMAIL" = "root@localhost"
потім
GIT_AUTHOR_EMAIL=[захищено електронною поштою]
експортувати GIT_AUTHOR_EMAIL
fi
якщо тест "$GIT_COMMITTER_EMAIL" = "root@localhost"
потім
GIT_COMMITTER_EMAIL=[захищено електронною поштою]
експортувати GIT_COMMITTER_EMAIL
fi
' -- -- все

Щоб обмежити перезапис лише частиною історії, вкажіть діапазон ревізій на додаток до
нову назву філії. Нова назва гілки вказуватиме на найвищу версію a мерзотник
рев-лист цього діапазону буде надруковано.

Розглянемо цю історію:

D--E--F--G--H
/ /
A--B-----C

Щоб переписати лише коміти D,E,F,G,H, але залишити A, B і C у спокої, використовуйте:

git filter-гілка ... C..H

Щоб переписати коміти E,F,G,H, скористайтеся одним із цих:

git filter-гілка ... C..H --не D
git filter-гілка ... D..H --не C

Щоб перемістити все дерево в підкаталог або видалити його звідти:

git filter-branch --index-filter \
'git ls-файли -s | sed "s-\t\"*-&newsubdir/-" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.новий \
git update-index --index-info &&
mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' ГОЛОВКА

КОНТРОЛЬНИЙ СПИСОК ДЛЯ СКОРЧЕННЯ A РЕПОЗИТОРІЙ

git-filter-branch можна використовувати, щоб позбутися підмножини файлів, зазвичай з деякими
комбінація --index-filter та --subdirectory-filter. Люди очікують результату
сховище має бути меншим за оригінал, але вам потрібно зробити ще кілька кроків
він менший, тому що Git намагається не втратити ваші об’єкти, поки ви не скажете йому. Спочатку
переконайтеся, що:

· Ви дійсно видалили всі варіанти назви файлу, якщо BLOB було переміщено протягом його життя.
git log --name-only --follow --all -- filename може допомогти вам знайти перейменування.

· Ви дійсно відфільтрували всі посилання: використовуйте --tag-name-filter cat -- --all під час виклику
git-filter-гілка.

Тоді є два способи отримати менший репозиторій. Більш безпечний спосіб - клонувати, це зберігається
ваш оригінал неушкоджений.

· Клонуйте його за допомогою git clone file:///path/to/repo. Клон не буде видалено
об'єкти. Побачити git-клон(1). (Зверніть увагу, що клонування за допомогою звичайного шляху лише жорсткі посилання
все!)

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

· Видаліть оригінальні посилання, підкріплені git-filter-branch: скажіть git for-each-ref
--format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d.

· Термін дії всіх reflogs з git reflog expire --expire=now --all.

· Сміття збирає всі об'єкти без посилання за допомогою git gc --prune=now (або якщо ваш git-gc
недостатньо новий для підтримки аргументів для --prune, використовуйте git repack -ad; git чорнослив
замість цього).

ПРИМІТКИ

git-filter-branch дозволяє вам робити складні переписування вашої історії Git за сценарієм оболонки,
але вам, ймовірно, не потрібна ця гнучкість, якщо ви просто видалення небажаний дані як
великі файли або паролі. Для цих операцій ви можете розглянути Команда BFG
Repo-Cleaner[1], альтернатива git-filter-branch на основі JVM, зазвичай принаймні 10-50x
швидше для цих випадків використання і з зовсім іншими характеристиками:

· Будь-яка конкретна версія файлу очищається точно один раз. BFG, на відміну від
git-filter-branch, не дає вам можливості обробляти файл по-іншому
на основі того, де чи коли це було скоєно у вашій історії. Це обмеження дає
Основна перевага продуктивності The BFG і добре підходить для очищення поганого
дані - вам байдуже де погані дані, ви просто цього хочете пішов.

· За замовчуванням BFG використовує всі переваги багатоядерних машин, очищаючи фіксацію
файлові дерева паралельно. git-filter-branch очищає коміти послідовно (тобто в a
однопотоковий спосіб), хоча це is можна написати фільтри, які включають свої власні
паралельність у сценаріях, що виконуються для кожного коміту.

· команда опції[2] є набагато більш обмежуючими, ніж гілка git-filter, і виділені
лише для завдань видалення небажаних даних, наприклад: --strip-blobs-bigger- than 1M.

GIT

Частина мерзотник(1) люкс

ПРИМІТКИ

1. BFG Repo-Cleaner
http://rtyley.github.io/bfg-repo-cleaner/

2. параметри команди
http://rtyley.github.io/bfg-repo-cleaner/#приклади

Використовуйте git-filter-branch онлайн за допомогою служб onworks.net