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

НАЗВА

git-repack - Пакування розпакованих об’єктів у репозиторій

СИНОПСИС

git repack [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [-m]
	[--window=<n>] [--depth=<n>] [--threads=<n>] [--keep-pack=<pack-name>]
	[--write-midx] [--name-hash-version=<n>] [--path-walk]

ОПИС

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

Пакет — це колекція об’єктів, окремо стиснутих із застосуванням дельта-стиснення, що зберігаються в одному файлі з пов’язаним індексним файлом.

Пакети використовуються для зменшення навантаження на системи дзеркал, механізми резервного копіювання, дискове сховище тощо.

ОПЦІЇ

-a

Замість поступового пакування розпакованих об’єктів, упакуйте все, на що посилаються, в один пакет. Особливо корисно під час пакування репозиторію, який використовується для приватної розробки. Використовуйте з -d. Це очистить об’єкти, які git prune залишає, але git fsck --full --dangling показує як висячі.

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

Пакетні файли Promisor перепаковуються окремо: якщо є пакетні файли, що мають пов’язаний файл ".promisor", ці пакетні файли будуть перепаковані в інший окремий пакет, і буде записано порожній файл ".promisor", що відповідає новому окремому пакету.

-A

Те саме, що й -a, якщо не використовується -d. Тоді будь-які недосяжні об’єкти в попередньому пакеті стають вільними, розпакованими об’єктами, замість того, щоб залишатися в старому пакеті. Недосяжні об’єкти ніколи навмисно не додаються до пакету, навіть під час перепаковування. Ця опція запобігає негайному видаленню недосяжних об’єктів шляхом їх залишення в старому пакеті, а потім видалення. Натомість, вільні недосяжні об’єкти будуть обрізані відповідно до звичайних правил закінчення терміну дії з наступним викликом git gc. Див. git-gc[1].

-d

Після пакування, якщо новостворені пакети роблять деякі існуючі пакети зайвими, видаліть ці зайві пакети. Також запустіть git prune-packed, щоб видалити зайві файли об’єктів.

--cruft

Те саме, що й -a, якщо не використовується -d. Тоді будь-які недосяжні об’єкти упаковуються в окремий cruft-пак. Недосяжні об’єкти можна видалити, використовуючи звичайні правила закінчення терміну дії, з наступним викликом git gc (див. git-gc[1]). Несумісно з -k.

--cruft-expiration=<approxidate>

Негайно видаляти недоступні об’єкти, старші за <approxidate>, замість очікування наступного виклику git gc. Корисно лише з --cruft -d.

--max-cruft-size=<n>

Перевизначає --max-pack-size для cruft-паків. За замовчуванням успадковує значення --max-pack-size (якщо є). Див. документацію щодо --max-pack-size для отримання додаткової інформації.

--combine-cruft-below-size=<n>

Під час створення cruft-паків без обрізання, перепаковуйте лише існуючі cruft-паки, розмір яких суворо менший за <n>, де <n> представляє кількість байтів, яка може мати суфікс "k", "m" або "g". Cruft-паки, розмір яких більший або дорівнює <n>, залишаються як є та не перепаковуються. Корисно, коли ви хочете уникнути перепаковування великих cruft-паків у репозиторіях, які містять багато та/або великі недоступні об’єкти.

--expire-to=<dir>

Записати cruft-пак, що містить обрізані об’єкти (якщо такі є), до каталогу <dir>. Ця опція корисна для зберігання копії будь-яких обрізаних об’єктів в окремому каталозі як резервної копії. Корисно лише з --cruft -d.

-l

Передайте параметр --local до git pack-objects. Див. git-pack-objects[1].

-f

Передайте параметр --no-reuse-delta до git-pack-objects, див. git-pack-objects[1].

-F

Передайте опцію --no-reuse-object до git-pack-objects, див. git-pack-objects[1].

-q
--quiet

Не показувати прогрес у стандартному потоці помилок та передати опцію -q до git pack-objects. Див. git-pack-objects[1].

-n

Не оновлюйте інформацію про сервер за допомогою git update-server-info. Цей параметр пропускає оновлення локальних файлів каталогу, необхідних для публікації цього репозиторію (або його прямої копії) через HTTP або FTP. Див. git-update-server-info[1].

--window=<n>
--depth=<n>

Ці два параметри впливають на те, як об’єкти, що містяться в пакеті, зберігаються за допомогою дельта-стиснення. Спочатку об’єкти сортуються внутрішньо за типом, розміром та (за бажанням) назвами, а потім порівнюються з іншими об’єктами в --window, щоб побачити, чи використання дельта-стиснення економить місце. --depth обмежує максимальну глибину дельти; занадто велика глибина впливає на продуктивність розпаковувача, оскільки до дельта-даних потрібно застосовувати так багато разів, щоб дістатися до потрібного об’єкта.

Значення за замовчуванням для --window дорівнює 10, а для --depth — 50. Максимальна глибина — 4095.

--threads=<n>

Цей параметр передається до git pack-objects.

--window-memory=<n>

Ця опція забезпечує додаткове обмеження на додаток до --window; розмір вікна динамічно зменшуватиметься, щоб не займати більше <n> байтів у пам’яті. Це корисно в репозиторіях із поєднанням великих та малих об’єктів, щоб не вичерпувати пам’ять для великого вікна, але все ще мати можливість використовувати переваги великого вікна для менших об’єктів. Розмір може мати суфікс "k", "m" або "g". --window-memory=0 робить використання пам’яті необмеженим. Значення за замовчуванням береться зі змінної конфігурації pack.windowMemory. Зверніть увагу, що фактичне використання пам’яті буде дорівнювати ліміту, помноженому на кількість потоків, що використовуються git-pack-objects[1].

--max-pack-size=<n>

Максимальний розмір кожного вихідного пакетного файлу. Розмір може мати суфікс "k", "m" або "g". Мінімально дозволений розмір обмежений 1 МіБ. Якщо вказано, можна створити кілька пакетних файлів, що також запобігає створенню растрового індексу. Значення за замовчуванням необмежене, якщо не встановлено змінну конфігурації pack.packSizeLimit. Зверніть увагу, що цей параметр може призвести до збільшення розміру репозиторію та його уповільнення; див. обговорення в pack.packSizeLimit.

--filter=<filter-spec>

Видаліть об’єкти, що відповідають специфікації фільтра, з результуючого пакет-файлу та помістіть їх в окремий пакет-файл. Зверніть увагу, що об’єкти, що використовуються в робочому каталозі, не фільтруються. Тому, щоб розділення повністю працювало, найкраще виконати його в чистому репозиторії та використовувати опції -a та -d разом з цією опцією. Також слід використовувати --no-write-bitmap-index (або опцію конфігурації repack.writebitmaps, встановлену на false), інакше запис індексу растрового зображення не вдасться, оскільки це передбачає один пакет-файл, що містить усі об’єкти. Дивіться git-rev-list[1] для коректних форм <filter-spec>.

--filter-to=<dir>

Запишіть пакет, що містить відфільтровані об’єкти, до каталогу <dir>. Корисно лише з --filter. Це можна використовувати для розміщення пакета в окремому каталозі об’єктів, доступ до якого здійснюється через механізм Git alternates. ПОПЕРЕДЖЕННЯ: Якщо пакетний файл, що містить відфільтровані об’єкти, недоступний, репозиторій може бути пошкоджений, оскільки доступ до об’єктів у цьому пакетному файлі може бути неможливим. Див. розділи objects та objects/info/alternates у gitrepository-layout[5].

-b
--write-bitmap-index

Записати індекс досяжності растрового зображення як частину перепакування. Це має сенс лише при використанні з -a, -A або -m, оскільки растрові зображення повинні мати можливість посилатися на всі досяжні об’єкти. Цей параметр замінює налаштування repack.writeBitmaps. Цей параметр не має ефекту, якщо створено кілька пакетних файлів, окрім випадків запису MIDX (у цьому випадку створюється багатопакове растрове зображення).

--pack-kept-objects

Включати об’єкти до файлів .keep під час перепаковування. Зверніть увагу, що ми все ще не видаляємо пакети .keep після завершення pack-objects. Це означає, що ми можемо дублювати об’єкти, але це робить цю опцію безпечною для використання під час одночасних надсилань або вибірок. Ця опція, як правило, корисна лише тоді, коли ви пишете растрові зображення з -b або repack.writeBitmaps, оскільки вона гарантує, що растровий пакет містить необхідні об’єкти.

--keep-pack=<pack-name>

Виключити вказаний пакет з перепаковки. Це еквівалентно наявності файлу .keep на пакеті. <назва-пакета> – це назва файлу пакета без початкового каталогу (наприклад, pack-123.pack). Цей параметр можна вказати кілька разів, щоб зберегти кілька пакетів.

--unpack-unreachable=<when>

Під час послаблення недоступних об’єктів не турбуйтеся про послаблення об’єктів, старших за <when>. Це можна використовувати для оптимізації запису будь-яких об’єктів, які будуть негайно видалені наступною командою git prune.

-k
--keep-unreachable

При використанні з -ad, будь-які недоступні об’єкти з існуючих пакетів будуть додані до кінця пакетного файлу, а не видалені. Крім того, будь-які недоступні вільні об’єкти будуть упаковані (а їхні вільні аналоги видалені).

-i
--delta-islands

Передайте параметр --delta-islands до git-pack-objects, див. git-pack-objects[1].

-g<factor>
--geometric=<factor>

Розташуйте результуючу структуру пакету таким чином, щоб кожен наступний пакет містив щонайменше <фактор>, помножений на кількість об’єктів, що перевищує кількість наступного за величиною пакету.

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

На відміну від інших режимів перепакування, набір об’єктів для пакування визначається однозначно набором пачок, що "згортаються"; іншими словами, пачками, які потрібно об’єднати для відновлення геометричної прогресії.

Вільні об’єкти неявно включені до цього "зведення", незалежно від їхньої досяжності. Це може змінитися в майбутньому.

Під час запису растрового зображення з кількох пакетів, git repack вибирає найбільший результуючий пакет як пріоритетний пакет для вибору об’єктів MIDX (див. git-multi-pack-index[1]).

-m
--write-midx

Напишіть індекс мультипаків (див. git-multi-pack-index[1]), що містить ненадлишкові пакети.

--name-hash-version=<n>

Надайте цей аргумент базовому процесу git pack-objects. Див. git-pack-objects[1] для отримання повної інформації.

--path-walk

Передайте параметр --path-walk базовому процесу git pack-objects. Див. git-pack-objects[1] для отримання повної інформації.

КОНФІГУРАЦІЯ

Різні змінні конфігурації впливають на пакування, див. git-config[1] (шукайте "pack" та "delta").

За замовчуванням команда передає опцію --delta-base-offset до git pack-objects; це зазвичай призводить до дещо менших пакетів, але згенеровані пакети несумісні з версіями Git, старішими за версію 1.4.4. Якщо вам потрібно поділитися своїм репозиторієм з такими старими версіями Git, безпосередньо або через незрозумілий http-протокол, тоді вам потрібно встановити змінну конфігурації repack.UseDeltaBaseOffset на "false" та перепакувати. Доступ зі старих версій Git через рідний протокол не залежить від цієї опції, оскільки в такому випадку конвертація виконується на льоту за потреби.

Дельта-стиснення не використовується для об’єктів, розмір яких перевищує значення змінної конфігурації core.bigFileThreshold, та для файлів з атрибутом delta, встановленим на false.

ДИВ. ТАКОЖ

git-pack-objects[1] git-prune-packed[1]

GIT

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