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

ОПИС

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

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

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

ОПЦІЇ

-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> байтів, які можна додатково доповнити суфіксом "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), інакше запис індексу бітових мап завершиться невдачею, оскільки передбачається наявність єдиного файлу packfile, що містить усі об’єкти. Дивіться git-rev-list[1] для дійсних форм <filter-spec>.

--filter-to=<dir>

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

-b
--write-bitmap-index

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

--pack-kept-objects

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

--keep-pack=<pack-name>

Виключити вказаний пакунок з перепакування. Це еквівалентно наявності файлу .keep у пакунку. <pack-name> — це ім’я файлу пакунка без початкової теки (наприклад, 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>

Впорядкувати отриману структуру пакунків таким чином, щоб кожен наступний пакунок містив щонайменше в <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]