'\" t
.\"     Title: git-pack-objects
.\"    Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net>
.\"      Date: 2026-06-29
.\"    Manual: Git Manual
.\"    Source: Git 2.55.0
.\"  Language: English
.\"
.TH "GIT\-PACK\-OBJECTS" "1" "2026\-06\-29" "Git 2\&.55\&.0" "Git Manual"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "نام (NAME)"
git-pack-objects \- ایجاد یک بایگانی فشرده و بسته‌بندی‌شده از اشیا
.SH "خلاصه دستور (SYNOPSIS)"
.sp
.nf
\fIgit pack\-objects\fR [\-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>
.fi
.sp
.SH "توضیحات (DESCRIPTION)"
.sp
فهرستی از اشیا را از ورودی استاندارد می‌خواند و یک یا چند بایگانی بسته‌بندی‌شده (pack) با نام پایه مشخص‌شده را روی دیسک می‌نویسد، یا یک بایگانی بسته‌بندی‌شده را به خروجی استاندارد ارسال می‌کند\&.
.sp
بایگانی بسته‌بندی‌شده روشی کارآمد برای انتقال مجموعه‌ای از اشیا میان دو مخزن و همچنین یک قالب بایگانی با دسترسی بهینه است\&. در یک بایگانی بسته‌بندی‌شده، هر شیء یا به‌صورت فشرده و کامل ذخیره می‌شود و یا به‌صورت تفاوت (دیف) نسبت به شیء دیگر نگهداری می‌گردد؛ که مورد دوم اغلب دلتا (delta) نامیده می‌شود\&.
.sp
قالب بایگانی بسته‌بندی‌شده (\&.pack) به‌گونه‌ای خودکفا طراحی شده است که بدون نیاز به اطلاعات تکمیلی بتوان آن را استخراج کرد\&. از این رو، هر شیئی که یک دلتا به آن وابسته است باید درون همان بسته (pack) موجود باشد\&.
.sp
یک فایل ایندکس بسته (\&.idx) برای دسترسی تصادفی و سریع به اشیای موجود در بسته تولید می‌شود\&. قرار دادن هم فایل ایندکس (\&.idx) و هم بایگانی بسته‌بندی‌شده (\&.pack) در زیرپوشه pack/ از $GIT_OBJECT_DIRECTORY (یا هر یک از دایرکتوری‌های موجود در $GIT_ALTERNATE_OBJECT_DIRECTORIES) به Git امکان می‌دهد تا از این بایگانی بسته بخواند\&.
.sp
دستور \fIgit unpack\-objects\fR می‌تواند بایگانی بسته‌بندی‌شده را خوانده و اشیای موجود در بسته را به قالب «یک شیء در هر فایل» باز کند؛ این کار معمولاً توسط دستورات واکشی هوشمند (smart-pull) هنگام ایجاد بسته در لحظه برای انتقال کارآمد روی شبکه توسط طرف‌های مقابل انجام می‌شود\&.
.SH "گزینه‌ها (OPTIONS)"
.PP
base\-name
.RS 4
نوشتن در جفت فایل‌های (\&.pack و \&.idx)، با استفاده از <base\-name> برای تعیین نام فایل ایجادشده\&. هنگامی که از این گزینه استفاده می‌شود، دو فایل یک جفت در فایل‌های <base\-name>\-<SHA\-1>\&.{pack,idx} نوشته می‌شوند\&. مقدار <SHA\-1> یک هش بر اساس محتوای بسته است و در خروجی استاندارد دستور نوشته می‌شود\&.
.RE
.PP
\-\-\stdout
.RS 4
نوشتن محتویات بسته (آنچه در فایل \&.pack نوشته می‌شد) در خروجی استاندارد\&.
.RE
.PP
\-\-\revs
.RS 4
خواندن آرگومان‌های بازنگری (revision) از ورودی استاندارد، به‌جای نام‌های تک‌تک اشیا\&. آرگومان‌های بازنگری به همان روشی پردازش می‌شوند که دستور
\fIgit rev\-list\fR
با فلگ
\fB\-\-\objects\fR
از آرگومان‌های
\fBcommit\fR
خود برای ساخت فهرست اشیای خروجی استفاده می‌کند\&. اشیای موجود در فهرست حاصل، بسته‌بندی می‌شوند\&. علاوه بر بازنگری‌ها، خطوط
\fB\-\-\not\fR
یا
\fB\-\-\shallow\fR
\fI<SHA\-1>\fR
نیز پذیرفته می‌شوند\&.
.RE
.PP
\-\-\unpacked
.RS 4
این گزینه مستلزم
\fB\-\-\revs\fR
است\&. هنگام پردازش فهرست آرگومان‌های بازنگری خوانده‌شده از ورودی استاندارد، اشیای بسته‌بندی‌شده را فقط به آن‌هایی محدود می‌کند که از قبل بسته‌بندی نشده‌اند\&.
.RE
.PP
\-\-\all
.RS 4
این گزینه مستلزم
\fB\-\-\revs\fR
است\&. علاوه بر فهرست آرگومان‌های بازنگری خوانده‌شده از ورودی استاندارد، چنان رفتار می‌کند که گویی تمام ارجاعات موجود در
\fBrefs/\fR
برای گنجانده شدن مشخص شده‌اند\&.
.RE
.PP
\-\-\include\-tag
.RS 4
شامل کردن برچسب‌های (تگ‌های) یادداشت‌دار درخواست‌نشده در صورتی که شیء مورد ارجاع آن‌ها در فایل بسته نهایی گنجانده شده باشد\&. این گزینه می‌تواند برای ارسال تگ‌های جدید به کلاینت‌های بومی Git مفید باشد\&.
.RE
.PP
\-\-\stdin\-packs[=<mode>]
.RS 4
خواندن نام پایه‌ای فایل‌های بسته (مانند
\fBpack\-1234abcd\&.pack\fR)
از ورودی استاندارد، به‌جای نام اشیا یا آرگومان‌های بازنگری\&. بسته نهایی شامل تمام اشیای فهرست‌شده در بسته‌های گنجانده‌شده (آن‌هایی که با
\fB^\fR
شروع نمی‌شوند) خواهد بود، به استثنای هر شیئی که در بسته‌های مستثنی‌شده (که با
\fB^\fR
شروع می‌شوند) آمده باشد\&.
.sp
هنگامی که
\fBmode\fR
برابر "follow" باشد، بسته‌ها می‌توانند علاوه بر این با علامت ! پیشوند شوند، که نشان می‌دهد آن‌ها مستثنی هستند اما لزوماً تحت دسترس‌پذیری بسته نشده‌اند\&. علاوه بر اشیای موجود در بسته‌های گنجانده‌شده، بسته نهایی ممکن است بر اساس موارد زیر شامل اشیای اضافی نیز باشد:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر بسته‌ای با ! مشخص شده باشد، اشیای در دسترس از این بسته‌ها یا بسته‌های گنجانده‌شده از طریق اشیایی خارج از بسته‌های مستثنی‌شده-بسته، گنجانده خواهند شد\&. در این حالت، تمام بسته‌های
\fB^\fR
تحت دسترس‌پذیری بسته در نظر گرفته می‌شوند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
در غیر این صورت (اگر هیچ بسته ! وجود نداشته باشد)، اشیای درون بسته‌های فهرست‌نشده در صورتی گنجانده می‌شوند که آن اشیا (۱) از بسته‌های گنجانده‌شده در دسترس باشند، و (۲) در هیچ‌یک از بسته‌های مستثنی‌شده یافت نشوند\&.
.RE
.sp
این حالت برای مثال برای احیای اشیایی که زمانی غیرقابل دسترس بوده‌اند و در بسته‌های بی‌استفاده (cruft) قرار دارند مفید است، تا بسته‌هایی تولید شوند که تا مرز تعیین‌شده توسط بسته‌های مستثنی‌شده تحت دسترس‌پذیری بسته باشند\&.
.sp
ناسازگار با
\fB\-\-\revs\fR،
یا گزینه‌هایی که مستلزم
\fB\-\-\revs\fR
هستند (مانند
\fB\-\-\all\fR)،
به استثنای
\fB\-\-\unpacked\fR
که سازگار است\&.
.RE
.PP
\-\-\cruft
.RS 4
اشیای غیرقابل دسترس را در یک بسته مجزای "cruft" که با وجود یک فایل
\fB\&.mtimes\fR
مشخص می‌شود بسته‌بندی می‌کند\&. معمولاً توسط
\fBgit\fR
\fBrepack\fR
\fB\-\-\cruft\fR
استفاده می‌شود\&. فراخوانندگان فهرستی از نام‌های بسته‌ها را ارائه داده و مشخص می‌کنند کدام بسته‌ها در مخزن باقی می‌مانند و کدام بسته‌ها حذف خواهند شد (که با پیشوند
\fB\-\fR
مشخص می‌شوند)\&. محتوای بسته cruft تمام اشیایی است که در بسته‌های باقی‌مانده وجود ندارند و از دوره مهلت تجاوز نکرده‌اند (به
\fB\-\-\cruft\-expiration\fR
در زیر مراجعه کنید)، یا از دوره مهلت فراتر رفته‌اند اما از شیء دیگری که فراتر نرفته قابل دسترس هستند\&.
.sp
هنگامی که ورودی بسته‌ای حاوی تمام اشیای قابل دسترس را فهرست کند (و همه بسته‌های دیگر را در انتظار حذف اعلام کند)، بسته cruft متناظر شامل تمام اشیای غیرقابل دسترس (با mtime جدیدتر از
\fB\-\-\cruft\-expiration\fR)
به همراه هر شیء غیرقابل دسترسی خواهد بود که mtime آن قدیمی‌تر از
\fB\-\-\cruft\-expiration\fR
است اما از یک شیء غیرقابل دسترس با mtime جدیدتر از
\fB\-\-\cruft\-expiration\fR
در دسترس است\&.
.sp
ناسازگار با
\fB\-\-\unpack\-unreachable\fR،
\fB\-\-\keep\-unreachable\fR،
\fB\-\-\pack\-loose\-unreachable\fR،
\fB\-\-\stdin\-packs\fR
و همچنین هر گزینه دیگری که مستلزم
\fB\-\-\revs\fR
باشد\&.
.RE
.PP
\-\-\cruft\-expiration=<approxidate>
.RS 4
در صورت مشخص شدن، اشیایی که mtime قدیمی‌تر از
\fI<approxidate>\fR
دارند از بسته cruft حذف می‌شوند\&. اگر مشخص نشود (و
\fB\-\-\cruft\fR
داده شده باشد)، هیچ شیئی حذف نخواهد شد\&.
.RE
.PP
\-\-\window=<n>, \-\-\depth=<n>
.RS 4
این دو گزینه بر چگونگی ذخیره‌سازی اشیای موجود در بسته با استفاده از فشرده‌سازی دلتا تأثیر می‌گذارند\&. اشیا ابتدا به صورت داخلی بر اساس نوع، اندازه و به‌صورت اختیاری نام مرتب شده و با سایر اشیای درون \-\-\window مقایسه می‌شوند تا مشخص شود آیا استفاده از فشرده‌سازی دلتا باعث صرفه‌جویی در فضا می‌شود یا خیر\&. گزینه \-\-\depth حداکثر عمق دلتا را محدود می‌کند؛ عمیق بودن بیش از حد آن بر کارایی سمت بازکننده بسته (unpacker) تأثیر منفی می‌گذارد، زیرا داده‌های دلتا برای رسیدن به شیء لازم باید به همان تعداد دفعات اعمال شوند\&.
.sp
مقدار پیش‌فرض برای \-\-\window برابر ۱۰ و برای \-\-\depth برابر ۵۰ است\&. حداکثر عمق ۴۰۹۵ است\&.
.RE
.PP
\-\-\window\-memory=<n>
.RS 4
این گزینه یک محدودیت اضافی علاوه بر
\fB\-\-\window\fR
ارائه می‌دهد؛ اندازه پنجره به‌طور پویا کاهش می‌یابد تا بیش از
\fI<n>\fR
بایت از حافظه را اشغال نکند\&. این گزینه در مخازنی با ترکیبی از اشیای بزرگ و کوچک مفید است تا با یک پنجره بزرگ حافظه تمام نشود، اما همچنان بتوان از مزیت پنجره بزرگ برای اشیای کوچک‌تر بهره برد\&. اندازه می‌تواند پسوندهای "k"، "m" یا "g" داشته باشد\&.
\fB\-\-\window\-memory=0\fR
استفاده از حافظه را نامحدود می‌کند\&. مقدار پیش‌فرض از متغیر پیکربندی
\fBpack\&.windowMemory\fR
گرفته می‌شود\&.
.RE
.PP
\-\-\max\-pack\-size=<n>
.RS 4
در سناریوهای غیرمعمول، ممکن است نتوانید فایل‌هایی بزرگ‌تر از اندازه‌ای مشخص در فایل‌سیستم خود ایجاد کنید، و از این گزینه می‌توان برای دستور دادن به برنامه جهت تقسیم فایل بسته خروجی به چندین فایل بسته مستقل استفاده کرد که اندازه هر یک بیشتر از مقدار داده‌شده نباشد\&. اندازه می‌تواند پسوند "k"، "m" یا "g" داشته باشد\&. حداقل اندازه مجاز به ۱ مبی‌بایت (MiB) محدود است\&. حالت پیش‌فرض نامحدود است، مگر اینکه متغیر پیکربندی
\fBpack\&.packSizeLimit\fR
تنظیم شده باشد\&. توجه داشته باشید که این گزینه ممکن است منجر به مخزنی بزرگ‌تر و کندتر شود؛ بحث مربوط به
\fBpack\&.packSizeLimit\fR
را ببینید\&.
.RE
.PP
\-\-\honor\-pack\-keep
.RS 4
این فلگ باعث می‌شود شیئی که از قبل در یک بسته محلی دارای فایل \&.keep قرار دارد نادیده گرفته شود، حتی اگر در غیر این صورت بسته‌بندی می‌شد\&.
.RE
.PP
\-\-\keep\-pack=<pack\-name>
.RS 4
این فلگ باعث می‌شود شیئی که از قبل در بسته داده‌شده قرار دارد نادیده گرفته شود، حتی اگر در غیر این صورت بسته‌بندی می‌شد\&.
\fI<pack\-name>\fR
نام فایل بسته بدون دایرکتوری ابتدایی است (مانند
\fBpack\-123\&.pack\fR)\&. این گزینه را می‌توان چندین بار برای نگه‌داشتن چند بسته مشخص کرد\&.
.RE
.PP
\-\-\incremental
.RS 4
این فلگ باعث می‌شود شیئی که از قبل در یک بسته قرار دارد نادیده گرفته شود، حتی اگر در غیر این صورت بسته‌بندی می‌شد\&.
.RE
.PP
\-\-\local
.RS 4
این فلگ باعث می‌شود شیئی که از یک مخزن اشیای جایگزین (alternate) به امانت گرفته شده نادیده گرفته شود، حتی اگر در غیر این صورت بسته‌بندی می‌شد\&.
.RE
.PP
\-\-\non\-empty
.RS 4
تنها در صورتی یک بایگانی بسته‌بندی‌شده ایجاد می‌کند که حداقل شامل یک شیء باشد\&.
.RE
.PP
\-\-\progress
.RS 4
وضعیت پیشرفت به‌طور پیش‌فرض هنگامی که خروجی خطای استاندارد به یک ترمینال متصل باشد گزارش می‌شود، مگر اینکه \-q مشخص شده باشد\&. این فلگ نمایش وضعیت پیشرفت را حتی اگر خطای استاندارد به ترمینال هدایت نشده باشد تحمیل می‌کند\&.
.RE
.PP
\-\-\all\-progress
.RS 4
هنگامی که \-\-\stdout مشخص شده باشد، گزارش پیشرفت در طول مراحل شمارش و فشرده‌سازی اشیا نمایش داده می‌شود اما در طول مرحله نوشتن غیرفعال می‌گردد\&. دلیل این امر آن است که در برخی موارد جریان خروجی مستقیماً به دستور دیگری متصل است که ممکن است بخواهد وضعیت پیشرفت خود را هنگام پردازش داده‌های بسته ورودی نمایش دهد\&. این فلگ شبیه به \-\-\progress است با این تفاوت که نمایش گزارش پیشرفت را برای مرحله نوشتن نیز تحمیل می‌کند، حتی اگر از \-\-\stdout استفاده شده باشد\&.
.RE
.PP
\-\-\all\-progress\-implied
.RS 4
این گزینه برای الزام ضمنی \-\-\all\-progress در هر زمانی که نمایش پیشرفت فعال است استفاده می‌شود\&. برخلاف \-\-\all\-progress، این فلگ به خودی خود هیچ نمایش پیشرفتی را تحمیل نمی‌کند\&.
.RE
.PP
\-q
.RS 4
این فلگ باعث می‌شود دستور وضعیت پیشرفت خود را روی جریان خطای استاندارد گزارش نکند\&.
.RE
.PP
\-\-\no\-reuse\-delta
.RS 4
هنگام ایجاد یک بایگانی بسته‌بندی‌شده در مخزنی که دارای بسته‌های موجود است، این دستور دلتاهای موجود را مجدداً استفاده می‌کند\&. این امر گاهی اوقات منجر به بسته‌ای تا حدی غیربهینه می‌شود\&. این فلگ به دستور می‌گوید دلتاهای موجود را دوباره استفاده نکند بلکه آن‌ها را از ابتدا محاسبه کند\&.
.RE
.PP
\-\-\no\-reuse\-object
.RS 4
این فلگ به دستور می‌گوید اصلاً داده‌های اشیای موجود را مجدداً استفاده نکند، از جمله اشیای دلتا‌نشده، و فشرده‌سازی مجدد همه چیز را تحمیل می‌کند\&. این گزینه مستلزم \-\-\no\-reuse\-delta است\&. تنها در موارد نادری مفید است که اعمال سراسری سطح فشرده‌سازی متفاوتی بر روی داده‌های بسته‌بندی‌شده مد نظر باشد\&.
.RE
.PP
\-\-\compression=<n>
.RS 4
سطح فشرده‌سازی را برای داده‌های تازه فشرده‌شده در بسته تولیدی مشخص می‌کند\&. در صورت عدم تعیین، سطح فشرده‌سازی بسته ابتدا توسط pack\&.compression و سپس توسط core\&.compression تعیین می‌شود و در صورتی که هیچ‌کدام تنظیم نشده باشند، مقدار پیش‌فرض آن \-1 (پیش‌فرض zlib) خواهد بود\&. اگر می‌خواهید بدون توجه به منبع، سطح فشرده‌سازی یکسانی را روی تمام داده‌ها تحمیل کنید، گزینه \-\-\no\-reuse\-object را اضافه کنید\&.
.RE
.PP
\-\-\sparse, \-\-\no\-sparse
.RS 4
الگوریتم "تُنُک" (sparse) را برای تعیین اشیایی که باید در بسته گنجانده شوند، هنگام ترکیب با گزینه "\-\-\revs" تغییر وضعیت می‌دهد\&. این الگوریتم تنها درخت‌هایی را پیمایش می‌کند که در مسیرهایی ظاهر می‌شوند که اشیای جدیدی معرفی کرده‌اند\&. این می‌تواند مزایای عملکردی چشمگیری هنگام محاسبه بسته برای ارسال یک تغییر کوچک داشته باشد\&. با این حال، ممکن است در صورتی که کامیت‌های گنجانده‌شده شامل انواع خاصی از تغییر نام‌های مستقیم باشند، اشیای اضافی به فایل بسته اضافه شوند\&. اگر این گزینه درج نشود، مقدار پیش‌فرض آن از
\fBpack\&.useSparse\fR
گرفته می‌شود که true است مگر اینکه خلاف آن مشخص شده باشد\&.
.RE
.PP
\-\-\thin
.RS 4
با حذف اشیای مشترک میان ارسال‌کننده و دریافت‌کننده یک بسته "نازک" (thin) ایجاد می‌کند تا انتقال شبکه را کاهش دهد\&. این گزینه تنها در ترکیب با \-\-\stdout معنا دارد\&.
.sp
نکته: یک بسته نازک با حذف اشیای مورد نیاز، فرمت بایگانی بسته‌بندی‌شده را نقض می‌کند و بنابراین تا زمانی که خودکفا نشود توسط Git غیرقابل استفاده است\&. برای بازیابی ویژگی خودکفایی از
\fBgit\fR
\fBindex\-pack\fR
\fB\-\-\fix\-thin\fR
(مراجعه به
\fBgit-index-pack\fR(1))
استفاده کنید\&.
.RE
.PP
\-\-\shallow
.RS 4
بهینه‌سازی بسته‌ای که قرار است به کلاینتی با مخزن کم‌عمق (shallow) ارائه شود\&. این گزینه در ترکیب با \-\-\thin می‌تواند با صرف هزینه سرعت، به بسته کوچک‌تری منجر شود\&.
.RE
.PP
\-\-\delta\-base\-offset
.RS 4
یک بایگانی بسته‌بندی‌شده می‌تواند شیء پایه یک دلتا را یا به صورت یک نام شیء ۲۰ بایتی یا به صورت یک آفست (فاصله) در جریان داده بیان کند، اما نسخه‌های بسیار قدیمی Git دومی را متوجه نمی‌شوند\&. به‌طور پیش‌فرض،
\fIgit pack\-objects\fR
تنها از قالب اول برای سازگاری بهتر استفاده می‌کند\&. این گزینه به دستور اجازه می‌دهد تا از فرمت آفست برای فشرده‌سازی و فشردگی بیشتر استفاده کند\&. بسته به میانگین طول زنجیره دلتا، این گزینه معمولاً فایل بسته حاصل را ۳ تا ۵ درصد کوچک‌تر می‌کند\&.
.sp
نکته: دستورات سطح بالا (Porcelain) مانند
\fBgit\fR
\fBgc\fR
(ببینید
\fBgit-gc\fR(1))،
\fBgit\fR
\fBrepack\fR
(ببینید
\fBgit-repack\fR(1))
در نسخه‌های مدرن Git این گزینه را به‌طور پیش‌فرض هنگام قرار دادن اشیا در فایل‌های بسته مخزن شما پاس می‌دهند\&. همچنین
\fBgit\fR
\fBbundle\fR
(ببینید
\fBgit-bundle\fR(1))
هنگام ساخت باندل این کار را انجام می‌دهد\&.
.RE
.PP
\-\-\threads=<n>
.RS 4
تعداد نخ‌هایی (threads) را مشخص می‌کند که هنگام جستجوی بهترین تطابق‌های دلتا ایجاد می‌شوند\&. این کار نیازمند آن است که pack\-objects با پشتیبانی از pthreads کامپایل شده باشد، در غیر این صورت این گزینه با یک هشدار نادیده گرفته می‌شود\&. این گزینه برای کاهش زمان بسته‌بندی در سیستم‌های چندپردازنده‌ای در نظر گرفته شده است\&. با این حال، مقدار حافظه مورد نیاز برای پنجره جستجوی دلتا در تعداد نخ‌ها ضرب می‌شود\&. مشخص کردن ۰ باعث می‌شود Git تعداد پردازنده‌ها را به‌طور خودکار شناسایی کرده و تعداد نخ‌ها را مطابق با آن تنظیم کند\&.
.RE
.PP
\-\-\index\-version=<version>[,<offset>]
.RS 4
این گزینه تنها برای استفاده در مجموعه آزمون‌ها در نظر گرفته شده است\&. این گزینه امکان می‌دهد تا نسخه ایندکس بسته تولیدشده تحمیل شود و ورودی‌های ایندکس ۶۴ بیتی برای اشیای واقع در بالای آفست داده‌شده تحمیل گردند\&.
.RE
.PP
\-\-\keep\-true\-parents
.RS 4
با این گزینه، والدینی که توسط پیوندها (grafts) پنهان شده‌اند با این حال بسته‌بندی می‌شوند\&.
.RE
.PP
\-\-\filter=<filter\-spec>
.RS 4
اشیای خاصی (معمولاً باینری‌ها یا blobها) را از فایل بسته نهایی حذف می‌کند\&. برای فرم‌های معتبر
\fI<filter\-spec>\fR
به
\fBgit-rev-list\fR(1)
مراجعه کنید\&.
.RE
.PP
\-\-\no\-filter
.RS 4
هر آرگومان پیشین
\fB\-\-\filter=\fR
را لغو می‌کند\&.
.RE
.PP
\-\-\missing=<missing\-action>
.RS 4
یک گزینه اشکال‌زدایی برای کمک به توسعه قابلیت "کلون جزئی" (partial clone) در آینده\&. این گزینه نحوه برخورد با اشیای گم‌شده را مشخص می‌کند\&.
.sp
فرم
\fI\-\-\missing=error\fR
درخواست می‌کند که در صورت مواجهه با یک شیء گم‌شده، pack\-objects با خطا متوقف شود\&. اگر مخزن یک کلون جزئی باشد، پیش از اعلام مفقودی اشیا، تلاشی برای واکشی آن‌ها انجام خواهد شد\&. این اقدام پیش‌فرض است\&.
.sp
فرم
\fI\-\-\missing=allow\-any\fR
در صورت مواجهه با شیء گم‌شده، اجازه می‌دهد تا پیمایش اشیا ادامه یابد\&. هیچ واکشی برای شیء گم‌شده انجام نخواهد شد\&. اشیای مفقود بدون اعلام خطا از نتایج حذف خواهند شد\&.
.sp
فرم
\fI\-\-\missing=allow\-promisor\fR
مانند
\fIallow\-any\fR
است، اما تنها برای اشیای مفقودِ مورد انتظار از سرور متهد (promisor) اجازه ادامه پیمایش را می‌دهد\&. هیچ واکشی برای شیء گم‌شده انجام نخواهد شد\&. مواجهه با شیء گم‌شده غیرمنتظره خطایی ایجاد خواهد کرد\&.
.RE
.PP
\-\-\exclude\-promisor\-objects
.RS 4
حذف اشیایی که مشخص است در ریموت متعهد (promisor) قرار دارند\&. (هدف این گزینه این است که فقط روی اشیای محلی ایجادشده عمل کند، به طوری که هنگام بسته‌بندی مجدد، همچنان تمایز میان اشیای محلی [بدون \&.promisor] و اشیای ریموت متعهد [دارای \&.promisor] حفظ شود)\&. این گزینه در کلون جزئی کاربرد دارد\&.
.RE
.PP
\-\-\keep\-unreachable
.RS 4
اشیای غیرقابل دسترس از ارجاعات در بسته‌های مشخص‌شده با گزینه \-\-\unpacked= به بسته حاصل اضافه می‌شوند، علاوه بر اشیای قابل دسترسی که در بسته‌های نشانه‌گذاری‌شده با فایل‌های *\&.keep نیستند\&. این گزینه مستلزم
\fB\-\-\revs\fR
است\&.
.RE
.PP
\-\-\pack\-loose\-unreachable
.RS 4
اشیای منفرد (loose) غیرقابل دسترس را بسته‌بندی می‌کند (و همتایان منفرد آن‌ها حذف می‌شوند)\&. این مستلزم
\fB\-\-\revs\fR
است\&.
.RE
.PP
\-\-\unpack\-unreachable
.RS 4
اشیای غیرقابل دسترس را در قالب منفرد (loose) نگه می‌دارد\&. این مستلزم
\fB\-\-\revs\fR
است\&.
.RE
.PP
\-\-\delta\-islands
.RS 4
تطابق‌های دلتا را بر اساس «جزیره‌ها» محدود می‌کند\&. بخش جزیره‌های دلتا را در زیر ببینید\&.
.RE
.PP
\-\-\name\-hash\-version=<n>
.RS 4
هنگام اجرای فشرده‌سازی دلتا، Git اشیایی را که ممکن است مشابه باشند، بر اساس روش‌های اکتشافی با استفاده از مسیر آن شیء گروه‌بندی می‌کند\&. در حالی که گروه‌بندی اشیا با تطابق دقیق مسیر برای مسیرهایی با نسخه‌های متعدد خوب است، یافتن جفت‌های دلتا در میان مسیرهای کامل متفاوت مزایایی به همراه دارد\&. Git اشیا را بر اساس نوع و سپس بر اساس یک «هش نام» از مسیر و سپس بر اساس اندازه جمع‌آوری می‌کند، با این امید که اشیایی را گروه‌بندی کند که با هم به خوبی فشرده می‌شوند\&.
.sp
نسخه پیش‌فرض هش نام برابر با
\fB1\fR
است که با در نظر گرفتن بایت‌های پایانی مسیر به عنوان بیشترین وزن برای تابع هش، اولویت را به محلی بودن هش می‌دهد\&. این نسخه در تشخیص مسیرهای کوتاه و یافتن تغییر نام‌ها در سراسر پوشه‌ها عالی عمل می‌کند\&. با این حال، تابع هش عمدتاً به ۱۶ بایت پایانی مسیر وابسته است\&. اگر مسیرهای زیادی در مخزن وجود داشته باشند که ۱۶ بایت پایانی یکسانی دارند و تنها در دایرکتوری والد تفاوت دارند، این هش نام ممکن است منجر به برخوردها (collisions) و تداخل‌های زیادی شود و نتایج ضعیفی به بار آورد\&. در حال حاضر، این نسخه هنگام نوشتن فایل‌های بیت‌مپ دسترس‌پذیری با
\fB\-\-\write\-bitmap\-index\fR
الزامی است\&.
.sp
نسخه
\fB2\fR
هش نام ویژگی‌های محلی مشابه نسخه
\fB1\fR
دارد، با این تفاوت که هر مؤلفه مسیر را به‌طور جداگانه در نظر می‌گیرد و هش‌ها را با یک شیفت روی هم قرار می‌دهد\&. این همچنان بایت‌های پایانی مسیر را در اولویت قرار می‌دهد، اما همچنین بیت‌های پایین‌تر هش را با استفاده از نام پوشه‌های والد «نمک‌سود» (salt) می‌کند\&. این روش امکان استفاده از برخی مزایای محلی نسخه
\fB1\fR
را فراهم می‌کند و در عین حال اکثر تداخل‌های ناشی از ظاهر شدن فایلی با نام مشابه در دایرکتوری‌های مختلف را از بین می‌برد\&. در حال حاضر، این نسخه هنگام نوشتن فایل‌های بیت‌مپ دسترس‌پذیری با
\fB\-\-\write\-bitmap\-index\fR
مجاز نیست و به‌طور خودکار به نسخه
\fB1\fR
تغییر خواهد یافت\&.
.RE
.PP
\-\-\path\-walk
.RS 4
فشرده‌سازی را ابتدا با سازماندهی اشیا بر اساس مسیر انجام می‌دهد، و سپس در مرحله دوم فشرده‌سازی بین مسیرها را طبق معمول اجرا می‌کند\&. این کار پتانسیل بهبود فشرده‌سازی دلتا را دارد، به‌ویژه در حضور نام فایل‌هایی که در الگوریتم پیش‌فرض هش نام Git باعث تداخل می‌شوند\&.
.sp
ناسازگار با
\fB\-\-\delta\-islands\fR\&.
گزینه
\fB\-\-\use\-bitmap\-index\fR
در حضور
\fB\-\-\path\-walk\fR
نادیده گرفته می‌شود\&. گزینه
\fB\-\-\path\-walk\fR
از فرم‌های
\fB\-\-\filter=\fR\fI<spec>\fR
زیر پشتیبانی می‌کند:
\fBblob:none\fR،
\fBblob:limit=\fR\fI<n>\fR،
\fBtree:0\fR،
\fBobject:type=\fR\fI<type>\fR
و
\fBsparse:\fR\fI<oid>\fR\&.
این انواع فیلترهای پشتیبانی‌شده را می‌توان با فرم
\fBcombine:\fR\fI<spec>\fR\fB+\fR\fI<spec>\fR
ترکیب کرد\&.
.RE
.SH "جزیره‌های دلتا (DELTA ISLANDS)"
.sp
در صورت امکان، \fBpack\-objects\fR سعی می‌کند از دلتاهای موجود روی دیسک مجدداً استفاده کند تا از جستجوی دلتاهای جدید در لحظه جلوگیری شود\&. این یک بهینه‌سازی مهم برای پاسخ به درخواست‌های واکشی (fetch) است، زیرا به این معنی است که سرور می‌تواند از باز کردن اکثر اشیا به‌طور کامل خودداری کرده و بایت‌ها را مستقیماً از روی دیسک ارسال کند\&. این بهینه‌سازی زمانی که یک شیء به عنوان دلتا نسبت به پایه‌ای ذخیره شده باشد که دریافت‌کننده آن را ندارد (و ما هم در حال ارسال آن نیستیم) نمی‌تواند کار کند\&. در این حالت سرور دلتا را می‌کند و باید دلتای جدیدی پیدا کند که هزینه پردازشی بالایی دارد\&. بنابراین برای عملکرد بسیار مهم است که مجموعه اشیا در روابط دلتای روی دیسک با آنچه کلاینت واکشی می‌کند مطابقت داشته باشد\&.
.sp
در یک مخزن معمولی، این امر تمایل دارد به‌طور خودکار کار کند\&. اشیا بیشتر از شاخه‌ها و برچسب‌ها قابل دسترس هستند و این همان چیزی است که کلاینت‌ها واکشی می‌کنند\&. هر دلتایی که در سرور پیدا می‌کنیم احتمالاً میان اشیایی است که کلاینت دارد یا خواهد داشت\&.
.sp
اما در برخی از پیکربندی‌های مخزن، ممکن است چندین گروه مرتبط اما جداگانه از سرشاخه‌ها (ref tips) داشته باشید، به طوری که کلاینت‌ها تمایل دارند آن گروه‌ها را به‌طور مستقل واکشی کنند\&. به عنوان مثال، تصور کنید که چندین انشعاب (fork) از یک مخزن را در یک مخزن اشیای مشترک میزبانی می‌کنید و به کلاینت‌ها اجازه می‌دهید از طریق \fBGIT_NAMESPACE\fR یا مخازن جداگانه با استفاده از سازوکار جایگزین‌ها (alternates) آن‌ها را به عنوان مخازن جداگانه مشاهده کنند\&. یک بسته‌بندی مجدد ساده‌لوحانه ممکن است به این نتیجه برسد که دلتای بهینه برای یک شیء نسبت به پایه‌ای است که فقط در یک فورک دیگر یافت می‌شود\&. اما هنگامی که یک کلاینت واکشی می‌کند، شیء پایه را نخواهد داشت و ما مجبور خواهیم شد یک دلتای جدید را در لحظه پیدا کنیم\&.
.sp
وضعیت مشابهی ممکن است وجود داشته باشد اگر ارجاعات زیادی خارج از \fBrefs/heads/\fR و \fBrefs/tags/\fR داشته باشید که به اشیای مرتبط اشاره می‌کنند (مانند \fBrefs/pull\fR یا \fBrefs/changes\fR که توسط برخی ارائه‌دهندگان میزبانی استفاده می‌شوند)\&. به‌طور پیش‌فرض، کلاینت‌ها فقط heads و tags را واکشی می‌کنند و دلتاها نسبت به اشیایی که فقط در آن گروه‌های دیگر یافت می‌شوند را نمی‌توان همان‌طور که هستند ارسال کرد\&.
.sp
جزیره‌های دلتا این مشکل را با اجازه دادن به شما برای گروه‌بندی ارجاعات خود در «جزیره‌های» متمایز حل می‌کنند\&. دستور Pack\-objects محاسبه می‌کند که کدام اشیا از کدام جزیره‌ها قابل دسترس هستند، و از ایجاد دلتا از شیء \fBA\fR نسبت به پایه‌ای که در تمام جزیره‌های \fBA\fR\*(Aqs وجود ندارد خودداری می‌کند\&. این منجر به بسته‌های کمی بزرگ‌تر می‌شود (چون برخی فرصت‌های دلتا را از دست می‌دهیم)، اما تضمین می‌کند که واکشی یک جزیره مجبور نخواهد بود به دلیل عبور از مرزهای جزیره، دلتاها را در لحظه دوباره محاسبه کند\&.
.sp
هنگام بسته‌بندی مجدد با جزیره‌های دلتا، پنجره دلتا تمایل دارد با کاندیداهایی که توسط پیکربندی ممنوع شده‌اند پر شود\&. بسته‌بندی مجدد با یک \-\-\window بزرگ کمک می‌کند (و آن‌قدر که در غیر این صورت ممکن است طول نمی‌کشد زیرا می‌توانیم برخی از جفت‌های اشیا را بر اساس جزیره‌ها پیش از انجام هرگونه محاسباتی روی محتوا رد کنیم)\&.
.sp
جزیره‌ها از طریق گزینه \fBpack\&.island\fR پیکربندی می‌شوند که می‌توان آن را چندین بار مشخص کرد\&. هر مقدار یک عبارت منظم چپ‌چین (left\-anchored) است که با نام‌های ارجاع مطابقت دارد\&. برای مثال:
.sp
.if n \{\
.RS 4
.\}
.nf
[pack]
island = refs/heads/
island = refs/tags/
.fi
.if n \{\
.RE
.\}
.sp
.sp
heads و tags را در یک جزیره قرار می‌دهد (که نام آن رشته خالی است؛ برای اطلاعات بیشتر در مورد نام‌گذاری به زیر مراجعه کنید)\&. هر ارجاعی که با این عبارت‌های منظم مطابقت نداشته باشد (مانند \fBrefs/pull/123\fR) در هیچ جزیره‌ای قرار نمی‌گیرد\&. بنابراین هر شیئی که فقط از \fBrefs/pull/\fR قابل دسترس باشد (نه heads یا tags) کاندیدایی برای استفاده به عنوان پایه برای \fBrefs/heads/\fR نخواهد بود\&.
.sp
ارجاعات بر اساس «نام»هایشان در جزیره‌ها گروه‌بندی می‌شوند و دو عبارت منظم که نام یکسانی تولید می‌کنند در یک جزیره در نظر گرفته می‌شوند\&. نام‌ها از عبارت‌های منظم با الحاق گروه‌های کپچر (capture groups) عبارت منظم به همراه یک خط تیره \fI\-\fR در بین آن‌ها محاسبه می‌شوند\&. (و اگر گروه کپچری وجود نداشته باشد، نام برابر رشته خالی است، مانند مثال بالا)\&. این به شما امکان می‌دهد تعداد دلخواهی از جزیره‌ها را ایجاد کنید\&. با این حال تنها تا ۱۴ گروه کپچر از این دست پشتیبانی می‌شود\&.
.sp
برای مثال، تصور کنید ارجاعات هر فورک را در \fBrefs/virtual/ID\fR ذخیره می‌کنید که در آن \fBID\fR یک شناسه عددی است\&. سپس می‌توانید چنین پیکربندی کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
[pack]
island = refs/virtual/([0\-9]+)/heads/
island = refs/virtual/([0\-9]+)/tags/
island = refs/virtual/([0\-9]+)/(pull)/
.fi
.if n \{\
.RE
.\}
.sp
.sp
این کار heads و tags را برای هر فورک در جزیره خودشان قرار می‌دهد (به نام "1234" یا مشابه آن)، و ارجاعات pull برای هر یک به "1234\-pull" اختصاصی خود می‌روند\&.
.sp
توجه داشته باشید که ما یک جزیره واحد را برای هر عبارت منظم انتخاب می‌کنیم تا در آن قرار گیرد، با استفاده از ترتیب «آخرین مورد برنده است» (که به پیکربندی ویژه مخزن اجازه می‌دهد بر پیکربندی سراسری کاربر اولویت داشته باشد، و الی آخر)\&.
.SH "پیکربندی (CONFIGURATION)"
.sp
متغیرهای پیکربندی گوناگونی بر بسته‌بندی تأثیر می‌گذارند؛ \fBgit-config\fR(1) را ببینید (به دنبال "pack" و "delta" بگردید)\&.
.sp
به‌ویژه، فشرده‌سازی دلتا بر روی اشیای بزرگ‌تر از مقدار متغیر پیکربندی \fBcore\&.bigFileThreshold\fR و روی فایل‌هایی با ویژگی \fBdelta\fR تنظیم‌شده روی false استفاده نمی‌شود\&.
.SH "همچنین ببینید (SEE ALSO)"
.sp
\fBgit-rev-list\fR(1) \fBgit-repack\fR(1) \fBgit-prune-packed\fR(1)
.SH "گیت (GIT)"
.sp
بخشی از مجموعه \fBgit\fR(1)