українська мова ▾ Topics ▾ Latest version ▾ git-pack-objects last updated in 2.54.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, коли їхні однорангові вузли створюють архів pack на льоту для ефективної передачі даних по мережі.

ОПЦІЇ

base-name

Записувати у пари файлів (.pack та .idx), використовуючи <base-name> для визначення імені створеного файлу. Коли використовується ця опція, два файли в парі записуються у файли <base-name>-<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

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

--stdin-packs[=<mode>]

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

Коли параметр mode має значення «follow», обʼєкти з пакунків, що не вказані у стандартному потоці вводу, обробляються особливим чином. Обʼєкти з пакунків, що не вказані у списку, будуть включені, якщо вони (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>

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

--honor-pack-keep

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

--keep-pack=<pack-name>

Цей прапорець призводить до ігнорування обʼєкта, який вже знаходиться у вказаному пакунку, навіть якщо він би був упакований. <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, якщо ви хочете примусово застосувати рівномірний рівень стиснення до всіх даних незалежно від джерела.

--sparse
--no-sparse

Керуйте алгоритмом «sparse», щоб визначити, які об’єкти включити до пакунка, у поєднанні з опцією «--revs». Цей алгоритм обробляє лише дерева, що з’являються у шляхах, які вводять нові об’єкти. Це може суттєво підвищити продуктивність під час обчислення пакунка для надсилання невеликих змін. Однак, можлива ситуація, коли до pack-файлу додаються додаткові об’єкти, якщо включені коміти містять певні типи прямих перейменувань. Якщо цей параметр не вказано, типовим значенням є 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 використовує лише перший формат для кращої сумісності. Ця опція дозволяє команді використовувати другий формат для компактності. Залежно від середньої довжини дельта-ланцюжка, ця опція зазвичай зменшує отриманий pack-файл на 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

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

--filter=<filter-spec>

Пропускає певні обʼєкти (зазвичай блоби) з отриманого pack-файлу. Див. 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] та обʼєктами з віддаленого 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]