GIT-PACK-OBJECTS(1) Git Manual GIT-PACK-OBJECTS(1)

git-pack-objects - ایجاد یک بایگانی فشرده و بسته‌بندی‌شده از اشیا

git pack-objects [-q | --rogress
| --ll-progress] [--ll-progress-implied]
                   [--0-reuse-delta] [--elta-base-offset] [--0n-empty]
                   [--
                   [--evs [--npacked | --ll]] [--ep-pack=<pack-name>]
                   [--ruft] [--ruft-expiration=<time>]
                   [--dout [--lter=<filter-spec>] | <base-name>]
                   [--allow] [--ep-true-parents] [--
                   [--0me-hash-version=<n>] [--ath-walk]
< <object-list>

فهرستی از اشیا را از ورودی استاندارد می‌خواند و یک یا چند بایگانی بسته‌بندی‌شده (pack) با نام پایه مشخص‌شده را روی دیسک می‌نویسد، یا یک بایگانی بسته‌بندی‌شده را به خروجی استاندارد ارسال می‌کند.

بایگانی بسته‌بندی‌شده روشی کارآمد برای انتقال مجموعه‌ای از اشیا میان دو مخزن و همچنین یک قالب بایگانی با دسترسی بهینه است. در یک بایگانی بسته‌بندی‌شده، هر شیء یا به‌صورت فشرده و کامل ذخیره می‌شود و یا به‌صورت تفاوت (دیف) نسبت به شیء دیگر نگهداری می‌گردد؛ که مورد دوم اغلب دلتا (delta) نامیده می‌شود.

قالب بایگانی بسته‌بندی‌شده (.pack) به‌گونه‌ای خودکفا طراحی شده است که بدون نیاز به اطلاعات تکمیلی بتوان آن را استخراج کرد. از این رو، هر شیئی که یک دلتا به آن وابسته است باید درون همان بسته (pack) موجود باشد.

یک فایل ایندکس بسته (.idx) برای دسترسی تصادفی و سریع به اشیای موجود در بسته تولید می‌شود. قرار دادن هم فایل ایندکس (.idx) و هم بایگانی بسته‌بندی‌شده (.pack) در زیرپوشه pack/ از $GIT_OBJECT_DIRECTORY (یا هر یک از دایرکتوری‌های موجود در $GIT_ALTERNATE_OBJECT_DIRECTORIES) به Git امکان می‌دهد تا از این بایگانی بسته بخواند.

دستور git unpack-objects می‌تواند بایگانی بسته‌بندی‌شده را خوانده و اشیای موجود در بسته را به قالب «یک شیء در هر فایل» باز کند؛ این کار معمولاً توسط دستورات واکشی هوشمند (smart-pull) هنگام ایجاد بسته در لحظه برای انتقال کارآمد روی شبکه توسط طرف‌های مقابل انجام می‌شود.

base-name

نوشتن در جفت فایل‌های (.pack و .idx)، با استفاده از <base-name> برای تعیین نام فایل ایجادشده. هنگامی که از این گزینه استفاده می‌شود، دو فایل یک جفت در فایل‌های <base-name>-<SHA-1>.{pack,idx} نوشته می‌شوند. مقدار <SHA-1> یک هش بر اساس محتوای بسته است و در خروجی استاندارد دستور نوشته می‌شود.

--dout

نوشتن محتویات بسته (آنچه در فایل .pack نوشته می‌شد) در خروجی استاندارد.

--evs

خواندن آرگومان‌های بازنگری (revision) از ورودی استاندارد، به‌جای نام‌های تک‌تک اشیا. آرگومان‌های بازنگری به همان روشی پردازش می‌شوند که دستور git rev-list با فلگ -- از آرگومان‌های commit خود برای ساخت فهرست اشیای خروجی استفاده می‌کند. اشیای موجود در فهرست حاصل، بسته‌بندی می‌شوند. علاوه بر بازنگری‌ها، خطوط --0t یا --allow <SHA-1> نیز پذیرفته می‌شوند.

--npacked

این گزینه مستلزم --evs است. هنگام پردازش فهرست آرگومان‌های بازنگری خوانده‌شده از ورودی استاندارد، اشیای بسته‌بندی‌شده را فقط به آن‌هایی محدود می‌کند که از قبل بسته‌بندی نشده‌اند.

--ll

این گزینه مستلزم --evs است. علاوه بر فهرست آرگومان‌های بازنگری خوانده‌شده از ورودی استاندارد، چنان رفتار می‌کند که گویی تمام ارجاعات موجود در refs/ برای گنجانده شدن مشخص شده‌اند.

--include-tag

شامل کردن برچسب‌های (تگ‌های) یادداشت‌دار درخواست‌نشده در صورتی که شیء مورد ارجاع آن‌ها در فایل بسته نهایی گنجانده شده باشد. این گزینه می‌تواند برای ارسال تگ‌های جدید به کلاینت‌های بومی Git مفید باشد.

--din-packs[=<mode>]

خواندن نام پایه‌ای فایل‌های بسته (مانند pack-1234abcd.pack) از ورودی استاندارد، به‌جای نام اشیا یا آرگومان‌های بازنگری. بسته نهایی شامل تمام اشیای فهرست‌شده در بسته‌های گنجانده‌شده (آن‌هایی که با ^ شروع نمی‌شوند) خواهد بود، به استثنای هر شیئی که در بسته‌های مستثنی‌شده (که با ^ شروع می‌شوند) آمده باشد.

هنگامی که mode برابر "follow" باشد، بسته‌ها می‌توانند علاوه بر این با علامت ! پیشوند شوند، که نشان می‌دهد آن‌ها مستثنی هستند اما لزوماً تحت دسترس‌پذیری بسته نشده‌اند. علاوه بر اشیای موجود در بسته‌های گنجانده‌شده، بسته نهایی ممکن است بر اساس موارد زیر شامل اشیای اضافی نیز باشد:

•اگر بسته‌ای با ! مشخص شده باشد، اشیای در دسترس از این بسته‌ها یا بسته‌های گنجانده‌شده از طریق اشیایی خارج از بسته‌های مستثنی‌شده-بسته، گنجانده خواهند شد. در این حالت، تمام بسته‌های ^ تحت دسترس‌پذیری بسته در نظر گرفته می‌شوند.
•در غیر این صورت (اگر هیچ بسته ! وجود نداشته باشد)، اشیای درون بسته‌های فهرست‌نشده در صورتی گنجانده می‌شوند که آن اشیا (۱) از بسته‌های گنجانده‌شده در دسترس باشند، و (۲) در هیچ‌یک از بسته‌های مستثنی‌شده یافت نشوند.

این حالت برای مثال برای احیای اشیایی که زمانی غیرقابل دسترس بوده‌اند و در بسته‌های بی‌استفاده (cruft) قرار دارند مفید است، تا بسته‌هایی تولید شوند که تا مرز تعیین‌شده توسط بسته‌های مستثنی‌شده تحت دسترس‌پذیری بسته باشند.

ناسازگار با --evs، یا گزینه‌هایی که مستلزم --evs هستند (مانند --ll)، به استثنای --npacked که سازگار است.

--ruft

اشیای غیرقابل دسترس را در یک بسته مجزای "cruft" که با وجود یک فایل .mtimes مشخص می‌شود بسته‌بندی می‌کند. معمولاً توسط git repack --ruft استفاده می‌شود. فراخوانندگان فهرستی از نام‌های بسته‌ها را ارائه داده و مشخص می‌کنند کدام بسته‌ها در مخزن باقی می‌مانند و کدام بسته‌ها حذف خواهند شد (که با پیشوند - مشخص می‌شوند). محتوای بسته cruft تمام اشیایی است که در بسته‌های باقی‌مانده وجود ندارند و از دوره مهلت تجاوز نکرده‌اند (به --ruft-expiration در زیر مراجعه کنید)، یا از دوره مهلت فراتر رفته‌اند اما از شیء دیگری که فراتر نرفته قابل دسترس هستند.

هنگامی که ورودی بسته‌ای حاوی تمام اشیای قابل دسترس را فهرست کند (و همه بسته‌های دیگر را در انتظار حذف اعلام کند)، بسته cruft متناظر شامل تمام اشیای غیرقابل دسترس (با mtime جدیدتر از --ruft-expiration) به همراه هر شیء غیرقابل دسترسی خواهد بود که mtime آن قدیمی‌تر از --ruft-expiration است اما از یک شیء غیرقابل دسترس با mtime جدیدتر از --ruft-expiration در دسترس است.

ناسازگار با --npack-unreachable، --ep-unreachable، --ack-loose-unreachable، --din-packs و همچنین هر گزینه دیگری که مستلزم --evs باشد.

--ruft-expiration=<approxidate>

در صورت مشخص شدن، اشیایی که mtime قدیمی‌تر از <approxidate> دارند از بسته cruft حذف می‌شوند. اگر مشخص نشود (و --ruft داده شده باشد)، هیچ شیئی حذف نخواهد شد.

--480

این دو گزینه بر چگونگی ذخیره‌سازی اشیای موجود در بسته با استفاده از فشرده‌سازی دلتا تأثیر می‌گذارند. اشیا ابتدا به صورت داخلی بر اساس نوع، اندازه و به‌صورت اختیاری نام مرتب شده و با سایر اشیای درون --7368

مقدار پیش‌فرض برای --1488

--360

این گزینه یک محدودیت اضافی علاوه بر --96 ارائه می‌دهد؛ اندازه پنجره به‌طور پویا کاهش می‌یابد تا بیش از <n> بایت از حافظه را اشغال نکند. این گزینه در مخازنی با ترکیبی از اشیای بزرگ و کوچک مفید است تا با یک پنجره بزرگ حافظه تمام نشود، اما همچنان بتوان از مزیت پنجره بزرگ برای اشیای کوچک‌تر بهره برد. اندازه می‌تواند پسوندهای "k"، "m" یا "g" داشته باشد. --312 استفاده از حافظه را نامحدود می‌کند. مقدار پیش‌فرض از متغیر پیکربندی pack.windowMemory گرفته می‌شود.

--x-pack-size=<n>

در سناریوهای غیرمعمول، ممکن است نتوانید فایل‌هایی بزرگ‌تر از اندازه‌ای مشخص در فایل‌سیستم خود ایجاد کنید، و از این گزینه می‌توان برای دستور دادن به برنامه جهت تقسیم فایل بسته خروجی به چندین فایل بسته مستقل استفاده کرد که اندازه هر یک بیشتر از مقدار داده‌شده نباشد. اندازه می‌تواند پسوند "k"، "m" یا "g" داشته باشد. حداقل اندازه مجاز به ۱ مبی‌بایت (MiB) محدود است. حالت پیش‌فرض نامحدود است، مگر اینکه متغیر پیکربندی pack.packSizeLimit تنظیم شده باشد. توجه داشته باشید که این گزینه ممکن است منجر به مخزنی بزرگ‌تر و کندتر شود؛ بحث مربوط به pack.packSizeLimit را ببینید.

--r-pack-keep

این فلگ باعث می‌شود شیئی که از قبل در یک بسته محلی دارای فایل .keep قرار دارد نادیده گرفته شود، حتی اگر در غیر این صورت بسته‌بندی می‌شد.

--ep-pack=<pack-name>

این فلگ باعث می‌شود شیئی که از قبل در بسته داده‌شده قرار دارد نادیده گرفته شود، حتی اگر در غیر این صورت بسته‌بندی می‌شد. <pack-name> نام فایل بسته بدون دایرکتوری ابتدایی است (مانند pack-123.pack). این گزینه را می‌توان چندین بار برای نگه‌داشتن چند بسته مشخص کرد.

--incremental

این فلگ باعث می‌شود شیئی که از قبل در یک بسته قرار دارد نادیده گرفته شود، حتی اگر در غیر این صورت بسته‌بندی می‌شد.

--

این فلگ باعث می‌شود شیئی که از یک مخزن اشیای جایگزین (alternate) به امانت گرفته شده نادیده گرفته شود، حتی اگر در غیر این صورت بسته‌بندی می‌شد.

--0n-empty

تنها در صورتی یک بایگانی بسته‌بندی‌شده ایجاد می‌کند که حداقل شامل یک شیء باشد.

--rogress

وضعیت پیشرفت به‌طور پیش‌فرض هنگامی که خروجی خطای استاندارد به یک ترمینال متصل باشد گزارش می‌شود، مگر اینکه -q مشخص شده باشد. این فلگ نمایش وضعیت پیشرفت را حتی اگر خطای استاندارد به ترمینال هدایت نشده باشد تحمیل می‌کند.

--ll-progress

هنگامی که --dout مشخص شده باشد، گزارش پیشرفت در طول مراحل شمارش و فشرده‌سازی اشیا نمایش داده می‌شود اما در طول مرحله نوشتن غیرفعال می‌گردد. دلیل این امر آن است که در برخی موارد جریان خروجی مستقیماً به دستور دیگری متصل است که ممکن است بخواهد وضعیت پیشرفت خود را هنگام پردازش داده‌های بسته ورودی نمایش دهد. این فلگ شبیه به --rogress
است با این تفاوت که نمایش گزارش پیشرفت را برای مرحله نوشتن نیز تحمیل می‌کند، حتی اگر از --dout استفاده شده باشد.

--ll-progress-implied

این گزینه برای الزام ضمنی --ll-progress در هر زمانی که نمایش پیشرفت فعال است استفاده می‌شود. برخلاف --ll-progress، این فلگ به خودی خود هیچ نمایش پیشرفتی را تحمیل نمی‌کند.

-q

این فلگ باعث می‌شود دستور وضعیت پیشرفت خود را روی جریان خطای استاندارد گزارش نکند.

--0-reuse-delta

هنگام ایجاد یک بایگانی بسته‌بندی‌شده در مخزنی که دارای بسته‌های موجود است، این دستور دلتاهای موجود را مجدداً استفاده می‌کند. این امر گاهی اوقات منجر به بسته‌ای تا حدی غیربهینه می‌شود. این فلگ به دستور می‌گوید دلتاهای موجود را دوباره استفاده نکند بلکه آن‌ها را از ابتدا محاسبه کند.

--0-reuse-object

این فلگ به دستور می‌گوید اصلاً داده‌های اشیای موجود را مجدداً استفاده نکند، از جمله اشیای دلتا‌نشده، و فشرده‌سازی مجدد همه چیز را تحمیل می‌کند. این گزینه مستلزم --0-reuse-delta است. تنها در موارد نادری مفید است که اعمال سراسری سطح فشرده‌سازی متفاوتی بر روی داده‌های بسته‌بندی‌شده مد نظر باشد.

--ompression=<n>

سطح فشرده‌سازی را برای داده‌های تازه فشرده‌شده در بسته تولیدی مشخص می‌کند. در صورت عدم تعیین، سطح فشرده‌سازی بسته ابتدا توسط pack.compression و سپس توسط core.compression تعیین می‌شود و در صورتی که هیچ‌کدام تنظیم نشده باشند، مقدار پیش‌فرض آن -1 (پیش‌فرض zlib) خواهد بود. اگر می‌خواهید بدون توجه به منبع، سطح فشرده‌سازی یکسانی را روی تمام داده‌ها تحمیل کنید، گزینه --0-reuse-object را اضافه کنید.

--arse, --0-sparse

الگوریتم "تُنُک" (sparse) را برای تعیین اشیایی که باید در بسته گنجانده شوند، هنگام ترکیب با گزینه "--evs" تغییر وضعیت می‌دهد. این الگوریتم تنها درخت‌هایی را پیمایش می‌کند که در مسیرهایی ظاهر می‌شوند که اشیای جدیدی معرفی کرده‌اند. این می‌تواند مزایای عملکردی چشمگیری هنگام محاسبه بسته برای ارسال یک تغییر کوچک داشته باشد. با این حال، ممکن است در صورتی که کامیت‌های گنجانده‌شده شامل انواع خاصی از تغییر نام‌های مستقیم باشند، اشیای اضافی به فایل بسته اضافه شوند. اگر این گزینه درج نشود، مقدار پیش‌فرض آن از pack.useSparse گرفته می‌شود که true است مگر اینکه خلاف آن مشخص شده باشد.

--hin

با حذف اشیای مشترک میان ارسال‌کننده و دریافت‌کننده یک بسته "نازک" (thin) ایجاد می‌کند تا انتقال شبکه را کاهش دهد. این گزینه تنها در ترکیب با --dout معنا دارد.

نکته: یک بسته نازک با حذف اشیای مورد نیاز، فرمت بایگانی بسته‌بندی‌شده را نقض می‌کند و بنابراین تا زمانی که خودکفا نشود توسط Git غیرقابل استفاده است. برای بازیابی ویژگی خودکفایی از git index-pack --x-thin (مراجعه به git-index-pack(1)) استفاده کنید.

--allow

بهینه‌سازی بسته‌ای که قرار است به کلاینتی با مخزن کم‌عمق (shallow) ارائه شود. این گزینه در ترکیب با --hin می‌تواند با صرف هزینه سرعت، به بسته کوچک‌تری منجر شود.

--elta-base-offset

یک بایگانی بسته‌بندی‌شده می‌تواند شیء پایه یک دلتا را یا به صورت یک نام شیء ۲۰ بایتی یا به صورت یک آفست (فاصله) در جریان داده بیان کند، اما نسخه‌های بسیار قدیمی Git دومی را متوجه نمی‌شوند. به‌طور پیش‌فرض، git pack-objects تنها از قالب اول برای سازگاری بهتر استفاده می‌کند. این گزینه به دستور اجازه می‌دهد تا از فرمت آفست برای فشرده‌سازی و فشردگی بیشتر استفاده کند. بسته به میانگین طول زنجیره دلتا، این گزینه معمولاً فایل بسته حاصل را ۳ تا ۵ درصد کوچک‌تر می‌کند.

نکته: دستورات سطح بالا (Porcelain) مانند git gc (ببینید git-gc(1))، git repack (ببینید git-repack(1)) در نسخه‌های مدرن Git این گزینه را به‌طور پیش‌فرض هنگام قرار دادن اشیا در فایل‌های بسته مخزن شما پاس می‌دهند. همچنین git bundle (ببینید git-bundle(1)) هنگام ساخت باندل این کار را انجام می‌دهد.

--hreads=<n>

تعداد نخ‌هایی (threads) را مشخص می‌کند که هنگام جستجوی بهترین تطابق‌های دلتا ایجاد می‌شوند. این کار نیازمند آن است که pack-objects با پشتیبانی از pthreads کامپایل شده باشد، در غیر این صورت این گزینه با یک هشدار نادیده گرفته می‌شود. این گزینه برای کاهش زمان بسته‌بندی در سیستم‌های چندپردازنده‌ای در نظر گرفته شده است. با این حال، مقدار حافظه مورد نیاز برای پنجره جستجوی دلتا در تعداد نخ‌ها ضرب می‌شود. مشخص کردن ۰ باعث می‌شود Git تعداد پردازنده‌ها را به‌طور خودکار شناسایی کرده و تعداد نخ‌ها را مطابق با آن تنظیم کند.

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

این گزینه تنها برای استفاده در مجموعه آزمون‌ها در نظر گرفته شده است. این گزینه امکان می‌دهد تا نسخه ایندکس بسته تولیدشده تحمیل شود و ورودی‌های ایندکس ۶۴ بیتی برای اشیای واقع در بالای آفست داده‌شده تحمیل گردند.

--ep-true-parents

با این گزینه، والدینی که توسط پیوندها (grafts) پنهان شده‌اند با این حال بسته‌بندی می‌شوند.

--lter=<filter-spec>

اشیای خاصی (معمولاً باینری‌ها یا blobها) را از فایل بسته نهایی حذف می‌کند. برای فرم‌های معتبر <filter-spec> به git-rev-list(1) مراجعه کنید.

--0-filter

هر آرگومان پیشین --lter= را لغو می‌کند.

--ssing=<missing-action>

یک گزینه اشکال‌زدایی برای کمک به توسعه قابلیت "کلون جزئی" (partial clone) در آینده. این گزینه نحوه برخورد با اشیای گم‌شده را مشخص می‌کند.

فرم --ssing=error درخواست می‌کند که در صورت مواجهه با یک شیء گم‌شده، pack-objects با خطا متوقف شود. اگر مخزن یک کلون جزئی باشد، پیش از اعلام مفقودی اشیا، تلاشی برای واکشی آن‌ها انجام خواهد شد. این اقدام پیش‌فرض است.

فرم --ssing=allow-any در صورت مواجهه با شیء گم‌شده، اجازه می‌دهد تا پیمایش اشیا ادامه یابد. هیچ واکشی برای شیء گم‌شده انجام نخواهد شد. اشیای مفقود بدون اعلام خطا از نتایج حذف خواهند شد.

فرم --ssing=allow-promisor مانند allow-any است، اما تنها برای اشیای مفقودِ مورد انتظار از سرور متهد (promisor) اجازه ادامه پیمایش را می‌دهد. هیچ واکشی برای شیء گم‌شده انجام نخواهد شد. مواجهه با شیء گم‌شده غیرمنتظره خطایی ایجاد خواهد کرد.

--\xclude-promisor-objects

حذف اشیایی که مشخص است در ریموت متعهد (promisor) قرار دارند. (هدف این گزینه این است که فقط روی اشیای محلی ایجادشده عمل کند، به طوری که هنگام بسته‌بندی مجدد، همچنان تمایز میان اشیای محلی [بدون .promisor] و اشیای ریموت متعهد [دارای .promisor] حفظ شود). این گزینه در کلون جزئی کاربرد دارد.

--ep-unreachable

اشیای غیرقابل دسترس از ارجاعات در بسته‌های مشخص‌شده با گزینه --npacked= به بسته حاصل اضافه می‌شوند، علاوه بر اشیای قابل دسترسی که در بسته‌های نشانه‌گذاری‌شده با فایل‌های *.keep نیستند. این گزینه مستلزم --evs است.

--ack-loose-unreachable

اشیای منفرد (loose) غیرقابل دسترس را بسته‌بندی می‌کند (و همتایان منفرد آن‌ها حذف می‌شوند). این مستلزم --evs است.

--npack-unreachable

اشیای غیرقابل دسترس را در قالب منفرد (loose) نگه می‌دارد. این مستلزم --evs است.

--elta-islands

تطابق‌های دلتا را بر اساس «جزیره‌ها» محدود می‌کند. بخش جزیره‌های دلتا را در زیر ببینید.

--0me-hash-version=<n>

هنگام اجرای فشرده‌سازی دلتا، Git اشیایی را که ممکن است مشابه باشند، بر اساس روش‌های اکتشافی با استفاده از مسیر آن شیء گروه‌بندی می‌کند. در حالی که گروه‌بندی اشیا با تطابق دقیق مسیر برای مسیرهایی با نسخه‌های متعدد خوب است، یافتن جفت‌های دلتا در میان مسیرهای کامل متفاوت مزایایی به همراه دارد. Git اشیا را بر اساس نوع و سپس بر اساس یک «هش نام» از مسیر و سپس بر اساس اندازه جمع‌آوری می‌کند، با این امید که اشیایی را گروه‌بندی کند که با هم به خوبی فشرده می‌شوند.

نسخه پیش‌فرض هش نام برابر با 1 است که با در نظر گرفتن بایت‌های پایانی مسیر به عنوان بیشترین وزن برای تابع هش، اولویت را به محلی بودن هش می‌دهد. این نسخه در تشخیص مسیرهای کوتاه و یافتن تغییر نام‌ها در سراسر پوشه‌ها عالی عمل می‌کند. با این حال، تابع هش عمدتاً به ۱۶ بایت پایانی مسیر وابسته است. اگر مسیرهای زیادی در مخزن وجود داشته باشند که ۱۶ بایت پایانی یکسانی دارند و تنها در دایرکتوری والد تفاوت دارند، این هش نام ممکن است منجر به برخوردها (collisions) و تداخل‌های زیادی شود و نتایج ضعیفی به بار آورد. در حال حاضر، این نسخه هنگام نوشتن فایل‌های بیت‌مپ دسترس‌پذیری با --384 الزامی است.

نسخه 2 هش نام ویژگی‌های محلی مشابه نسخه 1 دارد، با این تفاوت که هر مؤلفه مسیر را به‌طور جداگانه در نظر می‌گیرد و هش‌ها را با یک شیفت روی هم قرار می‌دهد. این همچنان بایت‌های پایانی مسیر را در اولویت قرار می‌دهد، اما همچنین بیت‌های پایین‌تر هش را با استفاده از نام پوشه‌های والد «نمک‌سود» (salt) می‌کند. این روش امکان استفاده از برخی مزایای محلی نسخه 1 را فراهم می‌کند و در عین حال اکثر تداخل‌های ناشی از ظاهر شدن فایلی با نام مشابه در دایرکتوری‌های مختلف را از بین می‌برد. در حال حاضر، این نسخه هنگام نوشتن فایل‌های بیت‌مپ دسترس‌پذیری با --384 مجاز نیست و به‌طور خودکار به نسخه 1 تغییر خواهد یافت.

--ath-walk

فشرده‌سازی را ابتدا با سازماندهی اشیا بر اساس مسیر انجام می‌دهد، و سپس در مرحله دوم فشرده‌سازی بین مسیرها را طبق معمول اجرا می‌کند. این کار پتانسیل بهبود فشرده‌سازی دلتا را دارد، به‌ویژه در حضور نام فایل‌هایی که در الگوریتم پیش‌فرض هش نام Git باعث تداخل می‌شوند.

ناسازگار با --elta-islands. گزینه --se-bitmap-index در حضور --ath-walk نادیده گرفته می‌شود. گزینه --ath-walk از فرم‌های --lter=<spec> زیر پشتیبانی می‌کند: blob:none، blob:limit=<n>، tree:0، object:type=<type> و sparse:<oid>. این انواع فیلترهای پشتیبانی‌شده را می‌توان با فرم combine:<spec>+<spec> ترکیب کرد.

در صورت امکان، pack-objects سعی می‌کند از دلتاهای موجود روی دیسک مجدداً استفاده کند تا از جستجوی دلتاهای جدید در لحظه جلوگیری شود. این یک بهینه‌سازی مهم برای پاسخ به درخواست‌های واکشی (fetch) است، زیرا به این معنی است که سرور می‌تواند از باز کردن اکثر اشیا به‌طور کامل خودداری کرده و بایت‌ها را مستقیماً از روی دیسک ارسال کند. این بهینه‌سازی زمانی که یک شیء به عنوان دلتا نسبت به پایه‌ای ذخیره شده باشد که دریافت‌کننده آن را ندارد (و ما هم در حال ارسال آن نیستیم) نمی‌تواند کار کند. در این حالت سرور دلتا را می‌کند و باید دلتای جدیدی پیدا کند که هزینه پردازشی بالایی دارد. بنابراین برای عملکرد بسیار مهم است که مجموعه اشیا در روابط دلتای روی دیسک با آنچه کلاینت واکشی می‌کند مطابقت داشته باشد.

در یک مخزن معمولی، این امر تمایل دارد به‌طور خودکار کار کند. اشیا بیشتر از شاخه‌ها و برچسب‌ها قابل دسترس هستند و این همان چیزی است که کلاینت‌ها واکشی می‌کنند. هر دلتایی که در سرور پیدا می‌کنیم احتمالاً میان اشیایی است که کلاینت دارد یا خواهد داشت.

اما در برخی از پیکربندی‌های مخزن، ممکن است چندین گروه مرتبط اما جداگانه از سرشاخه‌ها (ref tips) داشته باشید، به طوری که کلاینت‌ها تمایل دارند آن گروه‌ها را به‌طور مستقل واکشی کنند. به عنوان مثال، تصور کنید که چندین انشعاب (fork) از یک مخزن را در یک مخزن اشیای مشترک میزبانی می‌کنید و به کلاینت‌ها اجازه می‌دهید از طریق GIT_NAMESPACE یا مخازن جداگانه با استفاده از سازوکار جایگزین‌ها (alternates) آن‌ها را به عنوان مخازن جداگانه مشاهده کنند. یک بسته‌بندی مجدد ساده‌لوحانه ممکن است به این نتیجه برسد که دلتای بهینه برای یک شیء نسبت به پایه‌ای است که فقط در یک فورک دیگر یافت می‌شود. اما هنگامی که یک کلاینت واکشی می‌کند، شیء پایه را نخواهد داشت و ما مجبور خواهیم شد یک دلتای جدید را در لحظه پیدا کنیم.

وضعیت مشابهی ممکن است وجود داشته باشد اگر ارجاعات زیادی خارج از refs/heads/ و refs/tags/ داشته باشید که به اشیای مرتبط اشاره می‌کنند (مانند refs/pull یا refs/changes که توسط برخی ارائه‌دهندگان میزبانی استفاده می‌شوند). به‌طور پیش‌فرض، کلاینت‌ها فقط heads و tags را واکشی می‌کنند و دلتاها نسبت به اشیایی که فقط در آن گروه‌های دیگر یافت می‌شوند را نمی‌توان همان‌طور که هستند ارسال کرد.

جزیره‌های دلتا این مشکل را با اجازه دادن به شما برای گروه‌بندی ارجاعات خود در «جزیره‌های» متمایز حل می‌کنند. دستور Pack-objects محاسبه می‌کند که کدام اشیا از کدام جزیره‌ها قابل دسترس هستند، و از ایجاد دلتا از شیء A نسبت به پایه‌ای که در تمام جزیره‌های A's وجود ندارد خودداری می‌کند. این منجر به بسته‌های کمی بزرگ‌تر می‌شود (چون برخی فرصت‌های دلتا را از دست می‌دهیم)، اما تضمین می‌کند که واکشی یک جزیره مجبور نخواهد بود به دلیل عبور از مرزهای جزیره، دلتاها را در لحظه دوباره محاسبه کند.

هنگام بسته‌بندی مجدد با جزیره‌های دلتا، پنجره دلتا تمایل دارد با کاندیداهایی که توسط پیکربندی ممنوع شده‌اند پر شود. بسته‌بندی مجدد با یک --4200

جزیره‌ها از طریق گزینه pack.island پیکربندی می‌شوند که می‌توان آن را چندین بار مشخص کرد. هر مقدار یک عبارت منظم چپ‌چین (left-anchored) است که با نام‌های ارجاع مطابقت دارد. برای مثال:

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

heads و tags را در یک جزیره قرار می‌دهد (که نام آن رشته خالی است؛ برای اطلاعات بیشتر در مورد نام‌گذاری به زیر مراجعه کنید). هر ارجاعی که با این عبارت‌های منظم مطابقت نداشته باشد (مانند refs/pull/123) در هیچ جزیره‌ای قرار نمی‌گیرد. بنابراین هر شیئی که فقط از refs/pull/ قابل دسترس باشد (نه heads یا tags) کاندیدایی برای استفاده به عنوان پایه برای refs/heads/ نخواهد بود.

ارجاعات بر اساس «نام»هایشان در جزیره‌ها گروه‌بندی می‌شوند و دو عبارت منظم که نام یکسانی تولید می‌کنند در یک جزیره در نظر گرفته می‌شوند. نام‌ها از عبارت‌های منظم با الحاق گروه‌های کپچر (capture groups) عبارت منظم به همراه یک خط تیره - در بین آن‌ها محاسبه می‌شوند. (و اگر گروه کپچری وجود نداشته باشد، نام برابر رشته خالی است، مانند مثال بالا). این به شما امکان می‌دهد تعداد دلخواهی از جزیره‌ها را ایجاد کنید. با این حال تنها تا ۱۴ گروه کپچر از این دست پشتیبانی می‌شود.

برای مثال، تصور کنید ارجاعات هر فورک را در refs/virtual/ID ذخیره می‌کنید که در آن ID یک شناسه عددی است. سپس می‌توانید چنین پیکربندی کنید:

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

این کار heads و tags را برای هر فورک در جزیره خودشان قرار می‌دهد (به نام "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(1)

2026-06-29 Git 2.55.0