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

НАЗВА

git-pack-objects - Створити упакований архів об’єктів

СИНОПСИС

git pack-objects [-q | --progress | --all-progress] [--all-progress-implied]
		   [--no-reuse-delta] [--delta-base-offset] [--non-empty]
		   [--local] [--incremental] [--window=<n>] [--depth=<n>]
		   [--revs [--unpacked | --all]] [--keep-pack=<pack-name>]
		   [--cruft] [--cruft-expiration=<time>]
		   [--stdout [--filter=<filter-spec>] | <base-name>]
		   [--shallow] [--keep-true-parents] [--[no-]sparse]
		   [--name-hash-version=<n>] [--path-walk] < <object-list>

ОПИС

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

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

Формат упакованого архіву (.pack) розроблений як автономний, щоб його можна було розпакувати без будь-якої додаткової інформації. Тому кожен об’єкт, від якого залежить дельта, має бути присутнім у пакеті.

Для швидкого, випадкового доступу до об’єктів у пакеті створюється файл індексу пакету (.idx). Розміщення як файлу індексу (.idx), так і упакованого архіву (.pack) у підкаталозі pack/ каталогу $GIT_OBJECT_DIRECTORY (або будь-якому з каталогів у $GIT_ALTERNATE_OBJECT_DIRECTORIES) дозволяє Git читати дані з архіву пакету.

Команда git unpack-objects може зчитувати упакований архів та розгортати об’єкти, що містяться в пакеті, у формат "один файл-один об’єкт"; зазвичай це робиться за допомогою команд smart-pull, коли пакет створюється на льоту для ефективного мережевого транспортування його вузлами.

ОПЦІЇ

base-name

Записувати у пари файлів (.pack та .idx), використовуючи <базове-назва> для визначення імені створеного файлу. Коли використовується ця опція, два файли в парі записуються у файли <базове-назва>-<SHA-1>.{pack,idx}. <SHA-1> – це хеш на основі вмісту пакета, який записується у стандартний вивід команди.

--stdout

Вивести вміст пакета (те, що було б записано у файл .pack) на стандартний вивід.

--revs

Зчитувати аргументи ревізій зі стандартного вводу, а не назви окремих об’єктів. Аргументи ревізій обробляються так само, як і git rev-list з прапорцем --objects, який використовує свої аргументи commit для побудови списку об’єктів, які він виводить. Об’єкти у результуючому списку упаковуються. Окрім ревізій, також приймаються рядки --not або --shallow <SHA-1>.

--unpacked

Це означає --revs. Під час обробки списку аргументів ревізій, що зчитуються зі стандартного вводу, обмежте упаковані об’єкти тими, які ще не упаковані.

--all

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

--include-tag

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

--stdin-packs[=<mode>]

Зчитує базові назви пакетів (наприклад, pack-1234abcd.pack) зі стандартного вводу, замість назв об’єктів чи аргументів ревізій. Результуючий пакет містить усі об’єкти, перелічені у включених пакетах (ті, що не починаються з ^), за винятком будь-яких об’єктів, перелічених у виключених пакетах (що починаються з ^).

Коли mode має значення "follow", об’єкти з пакетів, не перелічених на stdin, отримують спеціальний режим. Об’єкти в пакетах, що не перелічені, будуть включені, якщо ці об’єкти (1) досяжні з включених пакетів та (2) не знайдені в жодному виключеному пакеті. Цей режим корисний, наприклад, для відновлення колись недосяжних об’єктів, знайдених у закритих пакетах, для створення пакетів, які закриті за досяжністю до межі, встановленої виключеними пакетами.

Несумісно з --revs або опціями, що мають на увазі --revs (наприклад, --all), за винятком --unpacked, яка сумісна.

--cruft

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

Коли вхідні дані містять пакет, що містить усі досяжні об’єкти (і всі інші пакети перераховуються як такі, що очікують на видалення), відповідний cruft-пак міститиме всі недосяжні об’єкти (з часом дії, новішим за --cruft-expiration), а також будь-які недосяжні об’єкти, mtime яких старший за --cruft-expiration, але досяжні з недосяжного об’єкта, mtime якого новіший за --cruft-expiration).

Несумісно з --unpack-unreachable, --keep-unreachable, --pack-loose-unreachable, --stdin-packs, а також будь-якими іншими опціями, що передбачають --revs.

--cruft-expiration=<approxidate>

Якщо вказано, об’єкти видаляються з cruft-паку, якщо їхнє значення mtime старше за <approxidate>. Якщо не вказано (і вказано --cruft), то жодні об’єкти не видаляються.

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

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

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

--window-memory=<n>

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

--max-pack-size=<n>

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

--honor-pack-keep

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

--keep-pack=<pack-name>

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

--incremental

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

--local

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

--non-empty

Створюйте упакований архів лише тоді, коли він містить хоча б один об’єкт.

--progress

Стан виконання за замовчуванням повідомляється у стандартному потоці помилок, коли він підключений до терміналу, якщо не вказано -q. Цей прапорець примусово повідомляє про стан виконання, навіть якщо стандартний потік помилок не спрямований до терміналу.

--all-progress

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

--all-progress-implied

Це використовується для позначення --all-progress щоразу, коли активовано відображення прогресу. На відміну від --all-progress, цей прапорець сам по собі не примусово відображає прогрес.

-q

Цей прапорець забороняє команді повідомляти про свій хід виконання у стандартному потоці помилок.

--no-reuse-delta

Під час створення упакованого архіву в репозиторії, який містить існуючі пакети, команда повторно використовує існуючі дельти. Іноді це призводить до дещо неоптимального пакету. Цей прапорець вказує команді не використовувати повторно існуючі дельти, а обчислювати їх з нуля.

--no-reuse-object

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

--compression=<n>

Визначає рівень стиснення для щойно стиснутих даних у згенерованому пакеті. Якщо не вказано, рівень стиснення пакета визначається спочатку за допомогою pack.compression, потім за допомогою core.compression, і за замовчуванням має значення -1, значення за замовчуванням zlib, якщо жоден з параметрів не встановлено. Додайте --no-reuse-object, якщо ви хочете примусово застосувати рівномірний рівень стиснення до всіх даних незалежно від джерела.

--[no-]sparse

Увімкніть алгоритм "sparse", щоб визначити, які об’єкти включити до пакету, у поєднанні з опцією "--revs". Цей алгоритм обходить лише дерева, що з’являються в шляхах, що вводять нові об’єкти. Це може мати значні переваги в продуктивності під час обчислення пакету для надсилання невеликих змін. Однак можливо, що до файлу пакету будуть додані додаткові об’єкти, якщо включені коміти містять певні типи прямих перейменувань. Якщо ця опція не включена, за замовчуванням використовується значення pack.useSparse, яке є true, якщо не вказано інше.

--thin

Створіть "тонкий" пакет, пропустивши спільні об’єкти між відправником та одержувачем, щоб зменшити мережеву передачу. Цей параметр має сенс лише в поєднанні з --stdout.

Примітка: Тонкий пакет порушує формат упакованого архіву, пропускаючи необхідні об’єкти, і тому Git не може використовувати його без створення автономного пакету. Використовуйте git index-pack --fix-thin (див. git-index-pack[1]) для відновлення автономної властивості.

--shallow

Оптимізуйте пакет, який буде надано клієнту з поверхневим репозиторієм. Цей параметр, у поєднанні з --thin, може призвести до зменшення розміру пакета за рахунок швидкості.

--delta-base-offset

Упакований архів може виражати базовий об’єкт дельти як 20-байтове ім’я об’єкта або як зміщення в потоці, але старі версії Git не розпізнають останнє. За замовчуванням git pack-objects використовує лише перший формат для кращої сумісності. Ця опція дозволяє команді використовувати другий формат для компактності. Залежно від середньої довжини дельта-ланцюжка, ця опція зазвичай зменшує результуючий пакет-файл на 3-5 відсотків.

Примітка: Команди Porcelain, такі як git gc (див. git-gc[1]), git repack (див. git-repack[1]), передають цю опцію за замовчуванням у сучасному Git, коли вони поміщають об’єкти з вашого репозиторію в файли пакетів. Те саме стосується git bundle (див. git-bundle[1]), коли створює пакет.

--threads=<n>

Вказує кількість потоків, які потрібно створити під час пошуку найкращих дельта-збігів. Це вимагає, щоб pack-objects були скомпільовані з pthreads, інакше цей параметр ігнорується з попередженням. Це призначено для скорочення часу пакування на багатопроцесорних машинах. Однак необхідний обсяг пам’яті для вікна пошуку дельта-збігів множиться на кількість потоків. Якщо вказати 0, Git автоматично визначить кількість процесорів і відповідно встановить кількість потоків.

--index-version=<version>[,<offset>]

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

--keep-true-parents

За допомогою цього варіанту батьки, приховані трансплантатами, все одно упаковані.

--filter=<filter-spec>

Пропускає певні об’єкти (зазвичай блоби) з результуючого пакет-файлу. Див. git-rev-list[1] для коректних форм <filter-spec>.

--no-filter

Вимикає будь-який попередній аргумент --filter=.

--missing=<missing-action>

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

Форма --missing=error вимагає, щоб pack-objects зупинилися з повідомленням про помилку, якщо виявлено відсутній об’єкт. Якщо репозиторій є частковим клоном, буде здійснено спробу отримати відсутні об’єкти, перш ніж оголосити їх відсутніми. Це дія за замовчуванням.

Форма --missing=allow-any дозволить продовжити обхід об’єкта, якщо буде виявлено відсутній об’єкт. Вибірка відсутнього об’єкта не відбудеться. Відсутні об’єкти будуть непомітно пропущені з результатів.

Форма --missing=allow-promisor подібна до allow-any, але дозволить продовження обходу об’єктів лише для ОЧІКУВАНИХ відсутніх об’єктів promisor. Вибірка відсутнього об’єкта не відбудеться. Неочікувано відсутній об’єкт викличе помилку.

--exclude-promisor-objects

Пропускати об’єкти, які, як відомо, знаходяться у віддаленому промісорі. (Цей параметр має на меті працювати лише з локально створеними об’єктами, щоб під час перепаковування ми все ще зберігали різницю між локально створеними об’єктами [без .promisor] та об’єктами з віддаленого промісора [з .promisor].) Це використовується з частковим клонуванням.

--keep-unreachable

Об’єкти, недоступні з посилань у пакетах з іменами, позначеними параметром --unpacked=, додаються до результуючого пакета, на додаток до досяжних об’єктів, які не знаходяться в пакетах, позначених файлами *.keep. Це означає --revs.

--pack-loose-unreachable

Упакувати недосяжні вільні об’єкти (та видалити їхні вільні аналоги). Це означає --revs.

--unpack-unreachable

Зберігайте недоступні об’єкти у вільній формі. Це означає --revs.

--delta-islands

Обмежити збіги дельт на основі "островів". Див. ОСТРОВИ ДЕЛЬТИ нижче.

--name-hash-version=<n>

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

Версія хешу імені за замовчуванням — 1, яка надає пріоритет локальності хешу, враховуючи кінцеві байти шляху як такі, що забезпечують максимальну величину для хеш-функції. Ця версія чудово розрізняє короткі шляхи та знаходить перейменування в різних каталогах. Однак хеш-функція залежить переважно від кінцевих 16 байтів шляху. Якщо в репозиторії є багато шляхів, які мають однакові кінцеві 16 байтів і відрізняються лише батьківським каталогом, то цей хеш імені може призвести до занадто великої кількості колізій та спричинити погані результати. Наразі ця версія потрібна під час запису файлів растрових зображень досяжності з --write-bitmap-index.

Хеш назви версії 2 має подібні характеристики локальності, як і версія 1, за винятком того, що вона розглядає кожен компонент шляху окремо та накладає хеші зі зсувом. Це все ще надає пріоритет останнім байтам шляху, але також "додає солі" молодшим бітам хешу, використовуючи назви батьківських каталогів. Цей метод дозволяє скористатися деякими перевагами локальності версії 1, одночасно усуваючи більшість колізій, пов’язаних з файлом з подібною назвою, який з’являється в багатьох різних каталогах. Наразі ця версія не дозволена під час запису файлів растрових зображень досяжності з --write-bitmap-index, і вона буде автоматично змінена на версію 1.

--path-walk

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

Несумісно з --delta-islands, --shallow або --filter. Опція --use-bitmap-index буде проігнорована за наявності --path-walk

ОСТРОВИ ДЕЛЬТИ

Коли це можливо, pack-objects намагається повторно використовувати існуючі дельти на диску, щоб уникнути необхідності пошуку нових на льоту. Це важлива оптимізація для обслуговування вибірок, оскільки це означає, що сервер може взагалі уникнути завищення більшості об’єктів і просто надсилати байти безпосередньо з диска. Ця оптимізація не може працювати, коли об’єкт зберігається як дельта з базою, якої немає у одержувача (і яку ми ще не надсилаємо). У такому випадку сервер "порушує" дельту і має знайти нову, яка має високі витрати процесора. Тому для продуктивності важливо, щоб набір об’єктів у дельта-зв’язках на диску відповідав тому, що отримав би клієнт.

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

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

Подібна ситуація може виникнути, якщо у вас є багато посилань поза refs/heads/ та refs/tags/, які вказують на пов’язані об’єкти (наприклад, refs/pull або refs/changes, що використовуються деякими хостинг-провайдерами). За замовчуванням клієнти отримують лише заголовки та теги, а дельти для об’єктів, знайдених лише в цих інших групах, не можуть бути надіслані як є.

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

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

Острови налаштовуються за допомогою опції pack.island, яку можна вказати кілька разів. Кожне значення є регулярним виразом з лівим прив’язком, що відповідає посиланням. Наприклад:

[pack]
island = refs/heads/
island = refs/tags/

поміщає заголовки та теги в острів (назва якого є порожнім рядком; див. нижче докладніше про іменування). Будь-які посилання, які не відповідають цим регулярним виразам (наприклад, refs/pull/123), не входять до жодного острова. Будь-який об’єкт, до якого можна дістатися лише з refs/pull/ (але не заголовки чи теги), тому не є кандидатом для використання як бази для refs/heads/.

Посилання групуються в острови на основі їхніх "імен", і два регулярні вирази, що дають однакову назву, вважаються такими, що знаходяться на одному острові. Назви обчислюються з регулярних виразів шляхом об’єднання будь-яких груп захоплення з регулярного виразу з тире - між ними. (А якщо груп захоплення немає, то назва є порожнім рядком, як у наведеному вище прикладі.) Це дозволяє створювати довільну кількість островів. Однак підтримується лише до 14 таких груп захоплення.

Наприклад, уявіть, що ви зберігаєте посилання для кожного відгалуження у refs/virtual/ID, де ID – це числовий ідентифікатор. Потім ви можете налаштувати:

[pack]
island = refs/virtual/([0-9]+)/heads/
island = refs/virtual/([0-9]+)/tags/
island = refs/virtual/([0-9]+)/(pull)/

Це розміщує головки та теги для кожної fork на окремому острові (з назвою "1234" або подібною), а посилання на pull для кожної з них потрапляють до окремого "1234-pull".

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

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

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

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

ДИВ. ТАКОЖ

git-rev-list[1] git-repack[1] git-prune-packed[1]

GIT

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