'\" t
.\"     Title: git-fast-import
.\"    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: Persian
.\"
.TH "GIT\-FAST\-IMPORT" "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-fast-import \- واردکننده سریع داده‌های گیت از سایر سامانه‌های کنترل نسخه
.SH "خلاصه دستور (SYNOPSIS)"
.sp
.nf
frontend | \fIgit fast\-import\fR [<\fIگزینه‌ها\fR>]
.fi
.sp
.SH "توضیحات (DESCRIPTION)"
.sp
این برنامه معمولاً چیزی نیست که کاربر نهایی بخواهد مستقیماً آن را اجرا کند\&. بیشتر کاربران نهایی مایلند از یکی از برنامه‌های پیشانی (frontend) موجود استفاده کنند که نوع خاصی از منبع خارجی را تجزیه کرده و محتویات ذخیره‌شده در آن را به \fIgit fast\-import\fR تحویل می‌دهد\&.
.sp
دستور fast\-import یک جریان ترکیبی از دستور/داده را از ورودی استاندارد می‌خواند و یک یا چند فایل بسته (packfile) را مستقیماً در مخزن جاری می‌نویسد\&. هنگامی که EOF در ورودی استاندارد دریافت می‌شود، fast import ارجاع‌های به‌روزشده شاخه و برچسب را می‌نویسد و مخزن جاری را با داده‌های تازه واردشده کاملاً به‌روز می‌کند\&.
.sp
بخش پشتیبان (backend) ابزار fast\-import می‌تواند داده‌ها را به درون یک مخزن خالی (مخزنی که پیش‌تر توسط \fIgit init\fR مقداردهی اولیه شده است) وارد کند یا یک مخزن پرشده موجود را به‌صورت افزایشی به‌روزرسانی نماید\&. اینکه آیا واردسازی افزایشی از یک منبع خارجی خاص پشتیبانی می‌شود یا خیر، به برنامه پیشانی مورد استفاده بستگی دارد\&.
.SH "گزینه‌ها (OPTIONS)"
.PP
\-\-force
.RS 4
به‌روزرسانی شاخه‌های تغییریافته موجود را اجبار می‌کند، حتی اگر این کار سبب از دست رفتن کامیت‌ها شود (زیرا کامیت جدید شامل کامیت قدیمی نیست)\&.
.RE
.PP
\-\-quiet
.RS 4
خروجی نمایش‌داده‌شده توسط \-\-stats را غیرفعال می‌کند و باعث می‌شود fast\-import معمولاً در صورت موفقیت‌آمیز بودن، بی‌صدا باشد\&. با این حال، اگر جریان واردسازی دارای دستورالعمل‌هایی باشد که برای نمایش خروجی به کاربر در نظر گرفته شده‌اند (مانند دستورالعمل‌های
\fBprogress\fR)،
پیام‌های مربوطه همچنان نمایش داده خواهند شد\&.
.RE
.PP
\-\-stats
.RS 4
برخی آمارهای اولیه را درباره اشیایی که fast\-import ایجاد کرده است، فایل‌های بسته‌ای که در آن‌ها ذخیره شده‌اند، و میزان حافظه استفاده‌شده توسط fast\-import در طول این اجرا نمایش می‌دهد\&. نمایش این خروجی در حال حاضر پیش‌فرض است، اما می‌توان آن را با \-\-quiet غیرفعال کرد\&.
.RE
.PP
\-\-allow\-unsafe\-features
.RS 4
بسیاری از گزینه‌های خط فرمان را می‌توان به عنوان بخشی از خود جریان fast\-import با استفاده از دستورات
\fBfeature\fR
یا
\fBoption\fR
ارائه داد\&. با این حال، برخی از این گزینه‌ها ناامن هستند (برای مثال، به fast\-import اجازه می‌دهند به سیستم فایل خارج از مخزن دسترسی داشته باشد)\&. این گزینه‌ها به‌طور پیش‌فرض غیرفعال هستند، اما می‌توان با ارائه این گزینه در خط فرمان اجازه استفاده از آن‌ها را صادر کرد\&. این موضوع در حال حاضر تنها بر دستورات ویژگیِ
\fBexport\-marks\fR،
\fBimport\-marks\fR و
\fBimport\-marks\-if\-exists\fR
تأثیر می‌گذارد\&.
.sp
این گزینه را تنها در صورتی فعال کنید که به برنامه تولیدکننده جریان fast\-import اعتماد دارید! این گزینه به‌طور خودکار برای برنامه‌های کمکی دوردست (remote\-helpers) که از قابلیت
\fBimport\fR
استفاده می‌کنند فعال می‌شود، چرا که آن‌ها از قبل برای اجرای کد خود مورد اعتماد هستند\&.
.RE
.PP
\fB\-\-signed\-tags=\fR\fI<mode>\fR
.RS 4
نحوه رسیدگی به برچسب‌های امضاشده را مشخص می‌کند\&. رفتاری مشابه با
\fB\-\-signed\-commits=\fR\fI<mode>\fR
در زیر دارد\&. مانند کامیت‌های امضاشده، حالت پیش‌فرض
\fBverbatim\fR
است\&.
.RE
.PP
\fB\-\-signed\-commits=\fR\fI<mode>\fR
.RS 4
نحوه رسیدگی به کامیت‌های امضاشده را مشخص می‌کند\&. حالت‌های <mode> زیر پشتیبانی می‌شوند:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBverbatim\fR، که پیش‌فرض است، امضاهای کامیت را در سکوت وارد می‌کند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBwarn\-verbatim\fR
آن‌ها را وارد می‌کند، اما یک هشدار نمایش می‌دهد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBabort\fR
هنگام مواجهه با یک کامیت امضاشده، اجرای این برنامه را متوقف می‌کند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBstrip\fR
در سکوت کامیت‌ها را بدون امضا می‌کند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBwarn\-strip\fR
آن‌ها را بدون امضا می‌کند، اما یک هشدار نمایش می‌دهد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBstrip\-if\-invalid\fR
امضاها را بررسی می‌کند و چنانچه نامعتبر باشند، آن‌ها را حذف کرده و یک هشدار نمایش می‌دهد\&. اعتبارسنجی به همان روشی انجام می‌شود که در
\fBgit-verify-commit\fR(1)
انجام می‌گیرد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBsign\-if\-invalid\fR[\fB=\fR\fI<keyid>\fR]، مشابه
\fBstrip\-if\-invalid\fR، امضاهای کامیت را بررسی می‌کند و امضاهای نامعتبر را با امضاهای تازه ایجادشده جایگزین می‌نماید\&. امضاهای معتبر دست‌نخورده باقی می‌مانند\&. اگر
\fI<keyid>\fR
ارائه شود، از آن کلید برای امضا استفاده می‌شود؛ در غیر این صورت از کلید امضای پیش‌فرض پیکربندی‌شده استفاده خواهد شد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBabort\-if\-invalid\fR
هنگام مواجهه با یک کامیت امضاشده که اعتبارسنجی آن امکان‌پذیر نباشد، اجرای این برنامه را متوقف خواهد کرد\&.
.RE
.RE
.SS "گزینه‌های برنامه‌های پیشانی (Options for Frontends)"
.PP
\-\-cat\-blob\-fd=<fd>
.RS 4
پاسخ‌های مربوط به پرس‌وجوهای
\fBget\-mark\fR،
\fBcat\-blob\fR و
\fBls\fR
را به جای
\fBstdout\fR
در توصیف‌کننده فایل <fd> می‌نویسد\&. این کار اجازه می‌دهد خروجی
\fBprogress\fR
که برای کاربر نهایی در نظر گرفته شده است، از سایر خروجی‌ها تفکیک شود\&.
.RE
.PP
\-\-date\-format=<fmt>
.RS 4
نوع تاریخ‌هایی را که برنامه پیشانی در دستورات
\fBauthor\fR،
\fBcommitter\fR
و
\fBtagger\fR
به fast\-import ارائه می‌دهد مشخص می‌کند\&. برای جزئیات بیشتر درباره قالب‌های پشتیبانی‌شده و نحو آن‌ها، بخش \(lqقالب‌های تاریخ (Date Formats)\(rq در ادامه را ببینید\&.
.RE
.PP
\-\-done
.RS 4
چنانچه دستور
\fBdone\fR
در انتهای جریان وجود نداشته باشد، با خطا پایان می‌یابد\&. این گزینه می‌تواند برای تشخیص خطاهایی که باعث پایان زودهنگام برنامه پیشانی پیش از آغاز نوشتن جریان می‌شوند مفید باشد\&.
.RE
.SS "مکان‌های فایل‌های نشان (Locations of Marks Files)"
.PP
\-\-export\-marks=<file>
.RS 4
پس از اتمام کار، جدول نشان‌های داخلی را در <file> تخلیه می‌کند\&. نشان‌ها در هر خط به صورت
\fB:markid\fR
\fBSHA\-1\fR
نوشته می‌شوند\&. برنامه‌های پیشانی می‌توانند از این فایل برای اعتبارسنجی واردسازی‌ها پس از تکمیل، یا ذخیره جدول نشان‌ها در طول اجراهای افزایشی استفاده کنند\&. از آنجا که <file> تنها در زمان نقطه بازرسی (یا تکمیل کار) باز و کوتاه (truncate) می‌شود، همان مسیر را می‌توان با اطمینان به \-\-import\-marks نیز داد\&.
.RE
.PP
\-\-import\-marks=<file>
.RS 4
پیش از پردازش هر ورودی، نشان‌های مشخص‌شده در <file> را بارگذاری می‌کند\&. فایل ورودی باید وجود داشته باشد، قابل خواندن باشد، و از همان قالبی استفاده کند که توسط \-\-export\-marks تولید می‌شود\&. برای وارد کردن بیش از یک مجموعه نشان، می‌توان گزینه‌های متعددی را مشخص کرد\&. اگر یک نشان با مقادیر متفاوتی تعریف شده باشد، مقدار آخرین فایل اولویت خواهد داشت\&.
.RE
.PP
\-\-import\-marks\-if\-exists=<file>
.RS 4
مشابه با \-\-import\-marks است، اما به جای ایجاد خطا، در صورتی که فایل وجود نداشته باشد در سکوت از آن صرف‌نظر می‌کند\&.
.RE
.PP
\-\-relative\-marks, \-\-no\-relative\-marks
.RS 4
پس از مشخص کردن \-\-relative\-marks، مسیرهای مشخص‌شده با \-\-import\-marks= و \-\-export\-marks= نسبت به یک دایرکتوری داخلی در مخزن جاری، نسبی در نظر گرفته می‌شوند\&. در git\-fast\-import این بدان معناست که مسیرها نسبت به دایرکتوری \&.git/info/fast\-import نسبی هستند\&. با این حال، سایر واردکننده‌ها ممکن است از مکان متفاوتی استفاده کنند\&.
.sp
نشان‌های نسبی و غیرنسبی را می‌توان با درهم‌آمیختن گزینه‌های \-\-(no\-)\-relative\-marks با گزینه‌های \-\-(import|export)\-marks= ترکیب کرد\&.
.RE
.SS "بازنویسی زیرماژول (Submodule Rewriting)"
.PP
\-\-rewrite\-submodules\-from=<name>:<file>, \-\-rewrite\-submodules\-to=<name>:<file>
.RS 4
شناسه‌های شیء (object IDs) را برای زیرماژول مشخص‌شده توسط <name>، از مقادیر استفاده‌شده در <file> مبدأ به مقادیر استفاده‌شده در <file> مقصد بازنویسی می‌کند\&. نشان‌های مبدأ (from) باید توسط
\fBgit\fR
\fBfast\-export\fR
ایجاد شده باشند، و نشان‌های مقصد (to) باید توسط
\fBgit\fR
\fBfast\-import\fR
هنگام واردسازی همان زیرماژول ایجاد شده باشند\&.
.sp
پارامتر <name> می‌تواند هر رشته دلخواهی باشد که فاقد نویسه دونقطه است، اما هنگام مشخص کردن نشان‌های متناظر باید از مقدار یکسانی در هر دو گزینه استفاده شود\&. می‌توان زیرماژول‌های متعددی را با مقادیر متفاوتی برای <name> مشخص کرد\&. استفاده نکردن از این گزینه‌ها در جفت‌های متناظر یک خطا به شمار می‌آید\&.
.sp
این گزینه‌ها در وهله اول هنگام تبدیل یک مخزن از یک الگوریتم درهم‌سازی به الگوریتمی دیگر مفید هستند؛ بدون آن‌ها، اگر fast\-import با یک زیرماژول روبه‌رو شود با شکست مواجه خواهد شد، چرا که راهی برای نوشتن شناسه شیء در الگوریتم درهم‌سازی جدید ندارد\&.
.RE
.SS "تنظیم کارایی و فشرده‌سازی (Performance and Compression Tuning)"
.PP
\-\-active\-branches=<n>
.RS 4
حداکثر تعداد شاخه‌هایی که می‌توان هم‌زمان فعال نگه داشت\&. برای جزئیات، بخش \(lqمصرف حافظه (MEMORY UTILIZATION)\(rq در زیر را ببینید\&. مقدار پیش‌فرض ۵ است\&.
.RE
.PP
\-\-big\-file\-threshold=<n>
.RS 4
حداکثر اندازه حبابی (blob) که fast\-import تلاش خواهد کرد برای آن دلتا بسازد، بیان‌شده به بایت\&. مقدار پیش‌فرض 512m (۵۱۲ مبی‌بایت) است\&. برخی از واردکننده‌ها ممکن است در سیستم‌هایی با حافظه محدود بخواهند این مقدار را کاهش دهند\&.
.RE
.PP
\-\-depth=<n>
.RS 4
حداکثر عمق دلتا، برای دلتاسازی حباب و درخت\&. مقدار پیش‌فرض ۵۰ است\&.
.RE
.PP
\-\-export\-pack\-edges=<file>
.RS 4
پس از ایجاد یک فایل بسته (packfile)، خطی از داده‌ها را در <file> چاپ می‌کند که نام فایل بسته و آخرین کامیت در هر شاخه‌ای را که در آن فایل بسته نوشته شده است فهرست می‌کند\&. این اطلاعات ممکن است پس از واردسازی پروژه‌هایی که کل مجموعه اشیاء آن‌ها از محدودیت ۴ گیبی‌بایتیِ فایل بسته فراتر می‌رود، مفید باشد؛ زیرا این کامیت‌ها را می‌توان به عنوان نقاط لبه در حین فراخوانی‌های
\fIgit pack\-objects\fR
به کار برد\&.
.RE
.PP
\-\-max\-pack\-size=<n>
.RS 4
حداکثر اندازه هر فایل بسته خروجی\&. مقدار پیش‌فرض نامحدود است\&.
.RE
.PP
fastimport\&.unpackLimit
.RS 4
به
\fBgit-config\fR(1)
مراجعه کنید\&.
.RE
.SH "کارایی (PERFORMANCE)"
.sp
طراحی fast\-import به آن امکان می‌دهد پروژه‌های بزرگ را با کمترین میزان مصرف حافظه و زمان پردازش وارد کند\&. با فرض اینکه فرانت‌اند بتواند پابه‌پای fast\-import پیش رود و جریانی مداوم از داده‌ها را به آن تغذیه کند، زمان واردسازی برای پروژه‌هایی با بیش از ۱۰ سال تاریخچه و حاوی بیش از ۱۰۰٬۰۰۰ کامیت مجزا، معمولاً تنها در ۱ تا ۲ ساعت روی سخت‌افزاری کاملاً متوسط (حدود ۲٬۰۰۰ دلار در سال ۲۰۰۷) به پایان می‌رسد\&.
.sp
بیشتر گلوگاه‌ها در دسترسی به داده‌های مبدأ خارجی (مبدأ صرفاً نمی‌تواند بازبینی‌ها را به اندازه کافی سریع استخراج کند) یا ورودی/خروجی دیسک (fast\-import با همان سرعتی که دیسک داده‌ها را می‌پذیرد می‌نویسد) رخ می‌دهند\&. در صورتی که داده‌های مبدأ روی درایوی متفاوت از مخزن مقصد گیت ذخیره شده باشند (به دلیل تداخل کمتر در ورودی/خروجی)، فرایند واردسازی سریع‌تر اجرا خواهد شد\&.
.SH "هزینه توسعه (DEVELOPMENT COST)"
.sp
یک فرانت‌اند معمولی برای fast\-import معمولاً در حدود ۲۰۰ خط کد Perl/Python/Ruby است\&. بیشتر توسعه‌دهندگان توانسته‌اند تنها در عرض چند ساعت واردکننده‌هایی کارآمد ایجاد کنند، حتی با وجود اینکه این نخستین مواجهه آن‌ها با fast\-import و گاهی حتی با گیت بوده است\&. با توجه به اینکه بیشتر ابزارهای تبدیل یک‌بارمصرف هستند (یک بار استفاده می‌شوند و دیگر به سراغ آن‌ها بازنمی‌گردند)، این یک وضعیت ایده‌آل است\&.
.SH "عملیات موازی (PARALLEL OPERATION)"
.sp
همانند \fIgit push\fR یا \fIgit fetch\fR، واردسازی‌های مدیریت‌شده توسط fast\-import را می‌توان با خیال راحت در کنار فراخوانی‌های موازی \fBgit\fR \fBrepack\fR \fB\-a\fR \fB\-d\fR یا \fBgit\fR \fBgc\fR، یا هر عملیات دیگر گیت (از جمله \fIgit prune\fR، زیرا اشیاء شل هرگز توسط fast\-import استفاده نمی‌شوند) اجرا کرد\&.
.sp
ابزار fast\-import ارجاعات شاخه یا برچسبی را که فعالانه در حال وارد کردن آن‌هاست قفل نمی‌کند\&. پس از واردسازی، در طول مرحله به‌روزرسانی ارجاع، fast\-import هر یک از ارجاعات موجود شاخه را بررسی می‌کند تا مطمئن شود به‌روزرسانی از نوع رو به جلو (fast\-forward) خواهد بود (کامیت ذخیره‌شده در ارجاع در تاریخچه جدید کامیتی که قرار است نوشته شود گنجانده شده باشد)\&. اگر به‌روزرسانی از نوع رو به جلو نباشد، fast\-import از به‌روزرسانی آن ارجاع صرف‌نظر می‌کند و در عوض یک پیام هشدار چاپ می‌نماید\&. ابزار fast\-import همیشه تلاش خواهد کرد تا تمام ارجاعات شاخه را به‌روزرسانی کند و با اولین شکست متوقف نمی‌شود\&.
.sp
به‌روزرسانی‌های شاخه را می‌توان با \-\-force اجبار کرد، اما توصیه می‌شود که این کار تنها در مخزنی انجام شود که در غیر این صورت آرام و بدون فعالیت دیگر است\&. استفاده از \-\-force برای واردسازی اولیه در یک مخزن خالی ضروری نیست\&.
.SH "بحث فنی (TECHNICAL DISCUSSION)"
.sp
ابزار fast\-import مجموعه‌ای از شاخه‌ها را در حافظه دنبال می‌کند\&. هر شاخه‌ای را می‌توان در هر نقطه‌ای از فرایند واردسازی با ارسال دستور \fBcommit\fR در جریان ورودی ایجاد یا اصلاح کرد\&. این طراحی به یک برنامه فرانت‌اند اجازه می‌دهد تعداد نامحدودی از شاخه‌ها را به طور هم‌زمان پردازش کند و کامیت‌ها را به ترتیبی که از داده‌های مبدأ در دسترس قرار می‌گیرند تولید نماید\&. این کار همچنین برنامه‌های فرانت‌اند را به میزان قابل توجهی ساده می‌سازد\&.
.sp
ابزار fast\-import از دایرکتوری کاری فعلی یا هر فایلی درون آن استفاده نکرده و آن را تغییر نمی‌دهد\&. (با این حال، مخزن فعلی گیت را، همان‌طور که توسط \fBGIT_DIR\fR ارجاع داده شده، به‌روزرسانی می‌کند\&.) بنابراین یک فرانت‌اند واردسازی می‌تواند از دایرکتوری کاری برای اهداف خود، مانند استخراج بازبینی‌های فایل از منبع خارجی استفاده کند\&. این نادیده گرفتن دایرکتوری کاری همچنین به fast\-import امکان می‌دهد بسیار سریع اجرا شود، زیرا هنگام جابه‌جایی میان شاخه‌ها نیازی به انجام هیچ عملیات پرهزینه به‌روزرسانی فایل ندارد\&.
.SH "قالب ورودی (INPUT FORMAT)"
.sp
به استثنای داده‌های خام فایل (که گیت آن‌ها را تفسیر نمی‌کند)، قالب ورودی fast\-import مبتنی بر متن (ASCII) است\&. این قالب متنی، توسعه و اشکال‌زدایی برنامه‌های فرانت‌اند را، به‌ویژه هنگامی که از زبانی سطح بالاتر مانند Perl، Python یا Ruby استفاده می‌شود، ساده می‌کند\&.
.sp
ابزار fast\-import درباره ورودی خود بسیار سخت‌گیر است\&. هر جا در زیر SP می‌گوییم، منظور \fBدقیقاً\fR یک فاصله است\&. به همین ترتیب LF به معنای یک (و فقط یک) خط‌شکن (linefeed) و HT به معنای یک (و فقط یک) تب افقی (horizontal tab) است\&. ارائه نویسه‌های فضای خالی اضافی باعث نتایج غیرمنتظره خواهد شد، مانند نام‌های شاخه یا نام‌های فایل با فاصله‌های ابتدایی یا انتهایی در نامشان، یا توقف زودهنگام fast\-import هنگامی که با ورودی غیرمنتظره روبه‌رو می‌شود\&.
.SS "توضیحات جریان (Stream Comments)"
.sp
به منظور کمک به اشکال‌زدایی فرانت‌اندها، fast\-import هر خطی را که با # (پوند/هش در ASCII) آغاز شود تا انتهای خط شامل \fBLF\fR نادیده می‌گیرد\&. یک خط توضیح می‌تواند شامل هر دنباله‌ای از بایت‌ها باشد که شامل LF نباشد و بنابراین می‌تواند برای گنجاندن هرگونه اطلاعات دقیق اشکال‌زدایی که ممکن است مختص فرانت‌اند بوده و هنگام بررسی جریان داده fast\-import مفید باشد، استفاده شود\&.
.SS "قالب‌های تاریخ (Date Formats)"
.sp
قالب‌های تاریخ زیر پشتیبانی می‌شوند\&. یک فرانت‌اند باید قالبی را که برای این واردسازی به کار خواهد برد، با ارسال نام قالب در گزینه خط فرمان \-\-date\-format=<fmt> انتخاب کند\&.
.PP
\fBraw\fR
.RS 4
این قالب بومی گیت است و به صورت
\fI<time>\fR
\fBSP\fR
\fI<offutc>\fR\&
می‌باشد\&. همچنین در صورتی که \-\-date\-format مشخص نشده باشد، این قالب پیش‌فرض fast\-import است\&.
.sp
زمان رویداد توسط
\fI<time>\fR
به عنوان تعداد ثانیه‌های سپری‌شده از مبدأ یونیکس (نیمه‌شب ۱ ژانویه ۱۹۷۰، ساعت هماهنگ جهانی UTC) مشخص می‌شود و به صورت یک عدد صحیح ده‌دهی ASCII نوشته می‌شود\&.
.sp
اختلاف محلی توسط
\fI<offutc>\fR
به عنوان اختلاف مثبت یا منفی از UTC مشخص می‌شود\&. برای مثال EST (که ۵ ساعت از UTC عقب‌تر است) در
\fI<tz>\fR
با \(lq\-0500\(rq بیان می‌شود در حالی که UTC به صورت \(lq+0000\(rq است\&. اختلاف محلی تأثیری بر
\fI<time>\fR
نمی‌گذارد؛ این مقدار صرفاً به عنوان توصیه‌ای برای کمک به روال‌های قالب‌بندی جهت نمایش برچسب زمان استفاده می‌شود\&.
.sp
اگر اختلاف محلی در داده‌های مبدأ در دسترس نباشد، از \(lq+0000\(rq یا متداول‌ترین اختلاف محلی استفاده کنید\&. برای مثال، بسیاری از سازمان‌ها یک مخزن CVS دارند که تاکنون تنها توسط کاربرانی که در همان مکان و منطقه زمانی مستقر بوده‌اند مورد دسترسی قرار گرفته است\&. در این حالت می‌توان اختلاف معقولی را از UTC فرض کرد\&.
.sp
برخلاف قالب
\fBrfc2822\fR،
این قالب بسیار سخت‌گیر است\&. هرگونه تغییر در قالب‌بندی باعث می‌شود fast\-import مقدار را رد کند، و ممکن است برخی بررسی‌های صحت‌سنجی بر روی مقادیر عددی نیز انجام شود\&.
.RE
.PP
\fBraw\-permissive\fR
.RS 4
این قالب همانند
\fBraw\fR
است، به جز اینکه هیچ بررسی صحت‌سنجی روی مقدار عددی مبدأزمانی و اختلاف محلی انجام نمی‌شود\&. این گزینه می‌تواند هنگام تلاش برای پالایش یا واردسازی یک تاریخچه موجود با مثلاً مقادیر ساختگی منطقه زمانی مفید باشد\&.
.RE
.PP
\fBrfc2822\fR
.RS 4
این قالب استاندارد تاریخ مطابق شرح RFC 2822 است\&.
.sp
یک مقدار نمونه \(lqTue Feb 6 11:22:18 2007 \-0500\(rq است\&. تجزیه‌کننده گیت دقیق است، اما کمی سهل‌گیرانه عمل می‌کند\&. این همان تجزیه‌کننده‌ای است که توسط
\fIgit am\fR
هنگام اِعمال وصله‌های دریافت‌شده از طریق ایمیل استفاده می‌شود\&.
.sp
برخی از رشته‌های بدشکل ممکن است به عنوان تاریخ‌های معتبر پذیرفته شوند\&. در برخی از این موارد گیت همچنان قادر خواهد بود تاریخ صحیح را از رشته بدشکل به دست آورد\&. همچنین انواعی از رشته‌های بدشکل وجود دارند که گیت آن‌ها را اشتباه تجزیه می‌کند، اما همچنان معتبر تلقی می‌نماید\&. رشته‌های به شدت بدشکل رد خواهند شد\&.
.sp
برخلاف قالب
\fBraw\fR
در بالا، اطلاعات منطقه زمانی/اختلاف UTC موجود در رشته تاریخ RFC 2822 برای تنظیم مقدار تاریخ به UTC پیش از ذخیره‌سازی استفاده می‌شود\&. بنابراین مهم است که این اطلاعات تا حد ممکن دقیق باشند\&.
.sp
اگر داده‌های مبدأ از تاریخ‌هایی به سبک RFC 2822 استفاده می‌کنند، فرانت‌اند باید اجازه دهد fast\-import تجزیه و تبدیل را مدیریت کند (به جای اینکه خودش تلاش کند آن را انجام دهد)، زیرا تجزیه‌کننده گیت در عمل به خوبی آزموده شده است\&.
.sp
فرانت‌اندها در صورتی که داده‌های مبدأ از قبل از قالب مبدأزمانی یونیکس (UNIX-epoch) استفاده می‌کنند، یا بتوان آن‌ها را به ارائه تاریخ در آن قالب ترغیب کرد، یا قالب آن‌ها به آسانی به آن قابل تبدیل باشد، باید قالب
\fBraw\fR
را ترجیح دهند، زیرا هیچ ابهامی در تجزیه وجود ندارد\&.
.RE
.PP
\fBnow\fR
.RS 4
همیشه از زمان و منطقه زمانی فعلی استفاده می‌کند\&. عبارت دقیق
\fBnow\fR
باید همیشه برای
\fI<when>\fR
ارائه شود\&.
.sp
این یک قالب نمایشی است\&. زمان و منطقه زمانی فعلی این سیستم همواره در زمان ایجاد توسط fast\-import در رشته هویت کپی می‌شود\&. هیچ راهی برای مشخص کردن زمان یا منطقه زمانی متفاوت وجود ندارد\&.
.sp
این قالب ویژه از آنجا ارائه شده است که پیاده‌سازی آن کوتاه است و ممکن است برای فرایندی مفید باشد که می‌خواهد همین حالا یک کامیت جدید ایجاد کند، بدون نیاز به استفاده از دایرکتوری کاری یا
\fIgit update\-index\fR\&.
.sp
اگر از دستورهای جداگانه
\fBauthor\fR
و
\fBcommitter\fR
در یک
\fBcommit\fR
استفاده شود، ممکن است برچسب‌های زمانی مطابقت نداشته باشند، زیرا ساعت سیستم دو بار (یک بار برای هر دستور) استعلام خواهد شد\&. تنها راه برای اطمینان از اینکه اطلاعات هویتی هر دو مؤلف و ثبت‌کننده دارای برچسب زمانی یکسانی باشند، حذف
\fBauthor\fR
(و در نتیجه کپی شدن از
\fBcommitter\fR)
یا استفاده از یک قالب تاریخ به غیر از
\fBnow\fR
است\&.
.RE
.SH "دستورها (COMMANDS)"
.sp
ابزار fast\-import چندین دستور را برای به‌روزرسانی مخزن فعلی و کنترل فرایند واردسازی جاری می‌پذیرد\&. بحث دقیق‌تر (همراه با مثال‌ها) درباره هر دستور در ادامه می‌آید\&.
.PP
\fBcommit\fR
.RS 4
با ایجاد یک کامیت جدید و به‌روزرسانی شاخه برای اشاره به کامیت تازه‌تولیدشده، یک شاخه جدید می‌سازد یا یک شاخه موجود را به‌روزرسانی می‌کند\&.
.RE
.PP
\fBtag\fR
.RS 4
یک شیء برچسب حاشیه‌نویسی‌شده (annotated tag) از روی یک کامیت یا شاخه موجود ایجاد می‌کند\&. برچسب‌های سبک (lightweight tags) توسط این دستور پشتیبانی نمی‌شوند، زیرا برای ثبت نقاط زمانی معنادار توصیه نمی‌گردند\&.
.RE
.PP
\fBreset\fR
.RS 4
یک شاخه موجود (یا یک شاخه جدید) را به یک بازبینی مشخص بازنشانی می‌کند\&. از این دستور باید برای تغییر یک شاخه به یک بازبینی مشخص بدون ایجاد کامیت روی آن استفاده شود\&.
.RE
.PP
\fBblob\fR
.RS 4
داده‌های خام فایل را به یک بلاب (blob) برای استفاده بعدی در یک دستور
\fBcommit\fR
تبدیل می‌کند\&. این دستور اختیاری است و برای انجام یک واردسازی به آن نیازی نیست\&.
.RE
.PP
\fBalias\fR
.RS 4
ثبت می‌کند که یک نشان (mark) بدون ایجاد هیچ شیء جدیدی در ابتدا، به یک شیء معین اشاره دارد\&. استفاده از \-\-import\-marks و ارجاع به نشان‌های ناموجود باعث شکست fast\-import خواهد شد، بنابراین نام‌های مستعار می‌توانند روشی برای تنظیم کامیت‌هایی که در غیر این صورت هرس (pruned) شده‌اند به یک مقدار معتبر (مانند نزدیک‌ترین نیای هرس‌نشده) فراهم کنند\&.
.RE
.PP
\fBcheckpoint\fR
.RS 4
دستور fast\-import را وادار می‌کند پک‌فایل فعلی را ببندد، چکسام SHA\-1 منحصربه‌فرد و ایندکس آن را تولید کند، و یک پک‌فایل جدید را آغاز نماید\&. این دستور اختیاری است و برای انجام یک واردسازی الزامی نیست\&.
.RE
.PP
\fBprogress\fR
.RS 4
باعث می‌شود fast\-import کل خط را در خروجی استاندارد خود بازتاب (echo) کند\&. این دستور اختیاری است و برای انجام یک واردسازی نیازی به آن نیست\&.
.RE
.PP
\fBdone\fR
.RS 4
پایان جریان داده را مشخص می‌کند\&. این دستور اختیاری است مگر اینکه ویژگی
\fBdone\fR
با استفاده از گزینه خط فرمان
\fB\-\-done\fR
یا دستور
\fBfeature\fR
\fBdone\fR
درخواست شده باشد\&.
.RE
.PP
\fBget\-mark\fR
.RS 4
باعث می‌شود fast\-import شناسه SHA\-1 متناظر با یک نشان را در توصیف‌گر فایل تنظیم‌شده با
\fB\-\-cat\-blob\-fd\fR،
یا در صورت نامشخص بودن در
\fBstdout\fR
چاپ کند\&.
.RE
.PP
\fBcat\-blob\fR
.RS 4
باعث می‌شود fast\-import یک بلاب را در قالب
\fIcat\-file \-\-batch\fR
در توصیف‌گر فایل تنظیم‌شده با
\fB\-\-cat\-blob\-fd\fR
یا در صورت نامشخص بودن در
\fBstdout\fR
چاپ کند\&.
.RE
.PP
\fBls\fR
.RS 4
باعث می‌شود fast\-import خطی در توصیف یک مدخل دایرکتوری در قالب
\fIls\-tree\fR
در توصیف‌گر فایل تنظیم‌شده با
\fB\-\-cat\-blob\-fd\fR
یا در صورت نامشخص بودن در
\fBstdout\fR
چاپ کند\&.
.RE
.PP
\fBfeature\fR
.RS 4
ویژگی مشخص‌شده را فعال می‌کند\&. این مستلزم آن است که fast\-import از ویژگی مشخص‌شده پشتیبانی کند، و اگر پشتیبانی نکند عملیات را متوقف می‌سازد\&.
.RE
.PP
\fBoption\fR
.RS 4
هر یک از گزینه‌های فهرست‌شده در OPTIONS را که معنای جریان داده را تغییر نمی‌دهند مشخص می‌کند تا با نیازهای فرانت‌اند سازگار شوند\&. این دستور اختیاری است و برای انجام یک واردسازی نیازی به آن نیست\&.
.RE
.SS "\fBcommit\fR"
.sp
یک شاخه را با یک کامیت جدید ایجاد یا به‌روزرسانی می‌کند و یک تغییر منطقی را در پروژه به ثبت می‌رساند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqcommit\*(Aq SP <ref> LF
        mark?
        original\-oid?
        (\*(Aqauthor\*(Aq (SP <name>)? SP LT <email> GT SP <when> LF)?
        \*(Aqcommitter\*(Aq (SP <name>)? SP LT <email> GT SP <when> LF
        (\*(Aqgpgsig\*(Aq SP <algo> SP <format> LF data)?
        (\*(Aqencoding\*(Aq SP <encoding> LF)?
        data
        (\*(Aqfrom\*(Aq SP <commit\-ish> LF)?
        (\*(Aqmerge\*(Aq SP <commit\-ish> LF)*
        (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
        LF?
.fi
.if n \{\
.RE
.\}
.sp
که در آن \fI<ref>\fR نام شاخه‌ای است که کامیت روی آن ثبت می‌شود\&. معمولاً در گیت نام‌های شاخه‌ها دارای پیشوند \fBrefs/heads/\fR هستند، بنابراین برای وارد کردن نشان شاخه CVS یعنی \fBRELENG\-1_0\fR، از \fBrefs/heads/RELENG\-1_0\fR برای مقدار \fI<ref>\fR استفاده می‌شود\&. مقدار \fI<ref>\fR باید یک نام مرجع (refname) معتبر در گیت باشد\&. از آنجا که \fBLF\fR در نام مرجع گیت مجاز نیست، هیچ نحوی برای نقل‌قول یا گریز (escape) در اینجا پشتیبانی نمی‌شود\&.
.sp
دستور \fBmark\fR می‌تواند به صورت اختیاری درج شود و از fast\-import درخواست کند تا یک مرجع به کامیت تازه‌ ایجادشده را برای استفاده‌های بعدی توسط فرانت‌اند ذخیره نماید (برای ساختار قالب به بخش زیر مراجعه کنید)\&. بسیار متداول است که فرانت‌اندها برای هر کامیتی که ایجاد می‌کنند نشانه‌ای ثبت نمایند، تا امکان ایجاد شاخه‌ها در آینده از هر کامیت واردشده فراهم باشد\&.
.sp
دستور \fBdata\fR که پس از \fBcommitter\fR می‌آید باید پیام کامیت را ارائه دهد (برای نحوه نگارش دستور \fBdata\fR به بخش زیر مراجعه کنید)\&. برای وارد کردن یک پیام کامیت خالی، از داده‌ای با طول ۰ استفاده کنید\&. پیام‌های کامیت دارای قالبی آزاد هستند و توسط گیت تفسیر نمی‌شوند\&. در حال حاضر آنها باید به صورت UTF\-8 کدگذاری شوند، چرا که fast\-import اجازه تعیین کدگذاری‌های دیگر را نمی‌دهد\&.
.sp
صفر یا چند دستور از دستورات \fBfilemodify\fR، \fBfiledelete\fR، \fBfilecopy\fR، \fBfilerename\fR، \fBfiledeleteall\fR و \fBnotemodify\fR می‌توانند برای به‌روزرسانی محتویات شاخه پیش از ایجاد کامیت گنجانده شوند\&. این دستورات را می‌توان به هر ترتیبی ارائه داد\&. با این حال توصیه می‌شود که در همان کامیت، دستور \fBfiledeleteall\fR پیش از تمام دستورات \fBfilemodify\fR، \fBfilecopy\fR، \fBfilerename\fR و \fBnotemodify\fR قرار گیرد، زیرا \fBfiledeleteall\fR شاخه را کاملاً پاکسازی می‌کند (بخش زیر را ببینید)\&.
.sp
نویسه \fBLF\fR بعد از دستور اختیاری است (پیش‌تر اجباری بود)\&. توجه داشته باشید که به دلایل سازگاری با نسخه‌های پیشین، اگر کامیت به یک دستور \fBdata\fR ختم شود (یعنی هیچ دستور \fBfrom\fR، \fBmerge\fR، \fBfilemodify\fR، \fBfiledelete\fR، \fBfilecopy\fR، \fBfilerename\fR، \fBfiledeleteall\fR یا \fBnotemodify\fR نداشته باشد)، آنگاه ممکن است به جای یکی، دو دستور \fBLF\fR در انتهای دستور ظاهر شوند\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBauthor\fR
.RS 4
.sp
دستور \fBauthor\fR در صورتی که اطلاعات نویسنده با اطلاعات کامیت‌کننده متفاوت باشد، می‌تواند به صورت اختیاری درج شود\&. اگر \fBauthor\fR حذف شود، fast\-import به طور خودکار از اطلاعات ثبت‌کننده (committer) برای بخش نویسنده کامیت استفاده خواهد کرد\&. برای شرح فیلدهای موجود در \fBauthor\fR به بخش زیر مراجعه کنید، زیرا این فیلدها با \fBcommitter\fR یکسان هستند\&.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBcommitter\fR
.RS 4
.sp
دستور \fBcommitter\fR مشخص می‌کند چه کسی این کامیت را ایجاد کرده و چه زمانی آن را ثبت نموده است\&.
.sp
در اینجا \fI<name>\fR نام نمایشی شخص (به عنوان مثال \(lqCom M Itter\(rq) و \fI<email>\fR نشانی ایمیل شخص (\(lqcm@example\&.com\(rq) است\&. \fBLT\fR و \fBGT\fR نمادهای عینی کوچکتری (\ex3c) و بزرگتری (\ex3e) هستند\&. وجود این نمادها برای تفکیک نشانی ایمیل از سایر فیلدهای درون خط الزامی است\&. توجه داشته باشید که \fI<name>\fR و \fI<email>\fR آزاد‌قالب بوده و می‌توانند حاوی هر دنباله‌ای از بایت‌ها به جز \fBLT\fR، \fBGT\fR و \fBLF\fR باشند\&. \fI<name>\fR معمولاً دارای کدگذاری UTF\-8 است\&.
.sp
زمان اعمال تغییر توسط \fI<when>\fR و با استفاده از قالب تاریخی که از طریق گزینه خط فرمان \-\-date\-format=<fmt> انتخاب شده است، مشخص می‌شود\&. برای مجموعه قالب‌های پشتیبانی‌شده و نحوه نگارش آنها، بخش \(lqDate Formats\(rq (قالب‌های تاریخ) در بالا را ببینید\&.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBgpgsig\fR
.RS 4
.sp
دستور اختیاری \fBgpgsig\fR برای گنجاندن یک امضای PGP/GPG یا سایر امضاهای رمزنگاری‌شده که داده‌های کامیت را امضا می‌کنند استفاده می‌شود\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqgpgsig\*(Aq SP <git\-hash\-algo> SP <signature\-format> LF data
.fi
.if n \{\
.RE
.\}
.sp
دستور \fBgpgsig\fR دو آرگومان می‌گیرد:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fI<git\-hash\-algo>\fR
مشخص می‌کند که این امضا بر کدام قالب شیء گیت اعمال می‌شود؛ که یا
\fBsha1\fR
است یا
\fBsha256\fR\&. این قابلیت امکان تشخیص این را فراهم می‌سازد که کدام بازنمایی از کامیت امضا شده است (نسخه SHA\-1 یا SHA\-256)، که هم به تأیید اعتبار امضا و هم به تعامل‌پذیری میان مخازنی با توابع درهم‌سازی متفاوت کمک می‌کند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fI<signature\-format>\fR
نوع امضا را مشخص می‌کند، مانند
\fBopenpgp\fR،
\fBx509\fR،
\fBssh\fR یا
\fBunknown\fR\&. این امر برای ابزارهایی که جریان را پردازش می‌کنند سهولت ایجاد می‌کند تا نیازی به تجزیه زره اسکی (ASCII armor) جهت شناسایی نوع امضا نداشته باشند\&.
.RE
.sp
یک کامیت می‌تواند حداکثر یک امضا برای قالب شیء SHA\-1 (ذخیره‌شده در سرایند "gpgsig") و یک امضا برای قالب شیء SHA\-256 (ذخیره‌شده در سرایند "gpgsig\-sha256") داشته باشد\&.
.sp
برای شرح مفصل دستور \fBdata\fR که حاوی داده‌های خام امضا است، بخش زیر را ببینید\&.
.sp
با این حال، در پیاده‌سازی فعلی امضاها هنوز بررسی نمی‌شوند\&. (تنظیم اولیه گزینه پیکربندی \fBextensions\&.compatObjectFormat\fR ممکن است در زمان پیاده‌سازی این ویژگی، به اعتبارسنجی امضاهای هر دو قالب شیء SHA\-1 و SHA\-256 کمک نماید\&.)
.if n \{\
.sp
.\}
.RS 4
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBیادداشت\fR
.ps -1
.br
.sp
این قابلیت بسیار آزمایشی است و قالب دستور \fBgpgsig\fR ممکن است در آینده بدون هیچ تضمینی برای سازگاری تغییر کند\&.
.sp .5v
.RE
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBencoding\fR
.RS 4
.sp
دستور اختیاری \fBencoding\fR کدگذاری پیام کامیت را مشخص می‌کند\&. بیشتر کامیت‌ها UTF\-8 هستند و کدگذاری ذکر نمی‌شود، اما این دستور اجازه می‌دهد پیام‌های کامیت بدون نیاز به کدگذاری مجدد اولیه وارد گیت شوند\&.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBfrom\fR
.RS 4
.sp
دستور \fBfrom\fR برای تعیین کامیتی استفاده می‌شود که این شاخه باید از آن مقداردهی اولیه شود\&. این بازنگری، اولین نیا (اجداد) کامیت جدید خواهد بود\&. وضعیت درخت ساخته‌شده در این کامیت با وضعیت موجود در کامیت \fBfrom\fR آغاز می‌شود و با اصلاحات محتوایی موجود در این کامیت تغییر می‌یابد\&.
.sp
حذف دستور \fBfrom\fR در اولین کامیت یک شاخه جدید باعث می‌شود که fast\-import آن کامیت را بدون هیچ نیایی ایجاد کند\&. این حالت معمولاً فقط برای کامیت اولیه یک پروژه مطلوب است\&. اگر فرانت‌اند هنگام ایجاد یک شاخه جدید همه فایل‌ها را از ابتدا ایجاد کند، می‌توان به جای \fBfrom\fR از دستور \fBmerge\fR استفاده نمود تا کامیت با یک درخت خالی آغاز شود\&. در شاخه‌های موجود، معمولاً صرف‌نظر کردن از دستور \fBfrom\fR مطلوب است، زیرا کامیت فعلی روی آن شاخه به طور خودکار به عنوان اولین نیا کامیت جدید فرض می‌شود\&.
.sp
از آنجا که \fBLF\fR در نام مرجع یا عبارت SHA\-1 گیت مجاز نیست، هیچ نحوی برای نقل‌قول یا گریز در درون \fI<commit\-ish>\fR پشتیبانی نمی‌شود\&.
.sp
در اینجا \fI<commit\-ish>\fR هر یک از موارد زیر است:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
نام یک شاخه موجود که هم‌اکنون در جدول شاخه‌های داخلی fast\-import وجود دارد\&. اگر fast\-import نام را نشناسد، با آن به عنوان یک عبارت SHA\-1 رفتار می‌شود\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
یک ارجاع نشان (mark reference)،
\fB:\fR\fI<idnum>\fR، که در آن
\fI<idnum>\fR
شماره نشان است\&.
.sp
دلیل اینکه fast\-import از
\fB:\fR
برای مشخص کردن ارجاع نشان استفاده می‌کند این است که این نویسه در نام شاخه‌های گیت مجاز نیست\&. نویسه پیشین
\fB:\fR
تفکیک میان نشان ۴۲ (\fB:42\fR) و شاخه ۴۲ (\fB42\fR
یا
\fBrefs/heads/42\fR)، یا یک SHA\-1 خلاصه‌شده که تصادفاً تنها از ارقام مبنای ۱۰ تشکیل شده را آسان می‌سازد\&.
.sp
نشان‌ها باید قبل از اینکه مورد استفاده قرار گیرند، (از طریق
\fBmark\fR) اعلان شوند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
یک مقدار کامل ۴۰ بایتی یا خلاصه‌شده SHA\-1 کامیت در مبنای ۱۶ (hex)\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
هر عبارت معتبر SHA\-1 در گیت که به یک کامیت منتهی شود\&. برای جزئیات، به بخش \(lqSPECIFYING REVISIONS\(rq در
\fBgitrevisions\fR(7)
مراجعه کنید\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
مقدار ویژه SHA\-1 تهی (۴۰ عدد صفر) که مشخص می‌کند شاخه باید حذف شود\&.
.RE
.sp
حالت خاص شروع مجدد یک واردسازی افزایشی از مقدار شاخه فعلی باید به این صورت نوشته شود:
.sp
.if n \{\
.RS 4
.\}
.nf
        from refs/heads/branch^0
.fi
.if n \{\
.RE
.\}
.sp
.sp
پسوند \fB^0\fR ضروری است زیرا fast\-import اجازه نمی‌دهد که یک شاخه از خودش شروع شود، و شاخه حتی قبل از اینکه دستور \fBfrom\fR از ورودی خوانده شود در حافظه ایجاد می‌گردد\&. افزودن \fB^0\fR باعث می‌شود fast\-import کامیت را از طریق کتابخانه تجزیه بازنگری گیت حل کند، نه جدول شاخه‌های داخلی خود، و بدین ترتیب مقدار موجود شاخه بارگذاری شود\&.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBmerge\fR
.RS 4
.sp
یک کامیت نیا (اجداد) اضافی را در بر می‌گیرد\&. پیوند نیاکانی اضافی، نحوه ساخت وضعیت درخت در این کامیت را تغییر نمی‌دهد\&. اگر هنگام ایجاد یک شاخه جدید دستور \fBfrom\fR حذف شود، اولین کامیت \fBmerge\fR به عنوان نخستین نیا کامیت فعلی در نظر گرفته خواهد شد و شاخه بدون هیچ فایلی کار خود را آغاز می‌کند\&. تعداد نامحدودی از دستورات \fBmerge\fR به ازای هر کامیت توسط fast\-import مجاز است و بدین ترتیب یک ادغام چندطرفه (n\-way merge) ایجاد می‌شود\&.
.sp
در اینجا \fI<commit\-ish>\fR هر یک از عبارت‌های تعیین کامیت است که توسط \fBfrom\fR نیز پذیرفته می‌شوند (بخش بالا را ببینید)\&.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBfilemodify\fR
.RS 4
.sp
در یک دستور \fBcommit\fR برای افزودن فایلی جدید یا تغییر محتوای فایلی موجود گنجانده می‌شود\&. این دستور دو روش مختلف برای مشخص کردن محتوای فایل دارد\&.
.PP
قالب داده خارجی (External data format)
.RS 4
محتوای داده برای فایل پیش‌تر توسط یک دستور قبلی
\fBblob\fR
تأمین شده است\&. فرانت‌اند فقط باید آن را متصل کند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(AqM\*(Aq SP <mode> SP <dataref> SP <path> LF
.fi
.if n \{\
.RE
.\}
.sp
در اینجا معمولاً
\fI<dataref>\fR
باید یا یک ارجاع نشان (\fB:\fR\fI<idnum>\fR) باشد که توسط یک دستور قبلی
\fBblob\fR
تنظیم شده است، یا SHA\-1 کامل ۴۰ بایتی از یک شیء blob موجود در گیت\&. اگر
\fI<mode>\fR
برابر با
\fB040000\fR
باشد، آنگاه
\fI<dataref>\fR
باید SHA\-1 کامل ۴۰ بایتی از یک شیء درختی (tree) موجود در گیت یا یک ارجاع نشان تنظیم‌شده با
\fB\-\-import\-marks\fR
باشد\&.
.RE
.PP
قالب داده درون‌خطی (Inline data format)
.RS 4
محتوای داده برای فایل هنوز تأمین نشده است\&. فرانت‌اند می‌خواهد آن را به عنوان بخشی از این دستور تغییر (modify) ارائه دهد\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(AqM\*(Aq SP <mode> SP \*(Aqinline\*(Aq SP <path> LF
        data
.fi
.if n \{\
.RE
.\}
.sp
برای شرح تفصیلی دستور
\fBdata\fR
به ادامه متن در زیر مراجعه کنید\&.
.RE
.sp
در هر دو قالب، \fI<mode>\fR نوع مدخل فایل است که در مبنای هشت (اکتال) مشخص می‌شود\&. گیت تنها از حالت‌های زیر پشتیبانی می‌کند:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fB100644\fR
یا
\fB644\fR: یک فایل معمولی (غیرقابل اجرا)\&. اکثریت فایل‌ها در بیشتر پروژه‌ها از این حالت استفاده می‌کنند\&. اگر تردید دارید، این همان حالتی است که می‌خواهید\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fB100755\fR
یا
\fB755\fR: یک فایل معمولی، اما قابل اجرا\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fB120000\fR: یک پیوند نمادین (symlink)؛ محتوای فایل، مقصد پیوند خواهد بود\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fB160000\fR: یک gitlink؛ کد SHA\-1 این شیء به یک کامیت در مخزنی دیگر ارجاع دارد\&. پیوندهای گیت تنها می‌توانند با SHA یا از طریق یک نشان (mark) کامیت مشخص شوند\&. آن‌ها برای پیاده‌سازی زیرماژول‌ها (submodules) به کار می‌روند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fB040000\fR: یک زیردایرکتوری\&. زیردایرکتوری‌ها را تنها می‌توان با SHA یا از طریق یک نشان درخت تنظیم‌شده با
\fB\-\-import\-marks\fR
مشخص کرد\&.
.RE
.sp
در هر دو قالب، \fI<path>\fR مسیر کامل فایلی است که باید اضافه شود (اگر از قبل وجود ندارد) یا تغییر یابد (اگر از قبل وجود دارد)\&.
.sp
یک \fI<path>\fR می‌تواند به صورت بایت‌های بدون نقل‌قول یا یک رشته نقل‌قول‌شده به سبک C نوشته شود\&.
.sp
هنگامی که یک \fI<path>\fR با یک علامت نقل‌قول دوتایی (") آغاز نمی‌شود، یک رشته بدون نقل‌قول است و به صورت بایت‌های لفظی بدون هیچ دنباله گریزی تجزیه می‌شود\&. با این حال، اگر نام فایل شامل \fBLF\fR باشد یا با علامت نقل‌قول دوتایی آغاز شود، نمی‌توان آن را به عنوان یک رشته بدون نقل‌قول نمایش داد و باید در نقل‌قول قرار گیرد\&. علاوه بر این، مسیر مبدأ \fI<path>\fR در \fBfilecopy\fR یا \fBfilerename\fR در صورتی که شامل SP باشد باید در نقل‌قول قرار گیرد\&.
.sp
هنگامی که یک \fI<path>\fR با یک علامت نقل‌قول دوتایی (") آغاز می‌شود، یک رشته نقل‌قول‌شده به سبک C است، که در آن نام کامل فایل در یک جفت علامت نقل‌قول دوتایی محصور شده و از دنباله‌های گریز استفاده می‌شود\&. برخی نویسه‌ها باید با قرار دادن یک بک‌اسلش پیش از آن‌ها گریز داده شوند: \fBLF\fR به صورت \fB\en\fR، بک‌اسلش به صورت \fB\e\e\fR، و علامت نقل‌قول دوتایی به صورت \fB\e\fR" نوشته می‌شود\&. برخی نویسه‌ها را می‌توان به صورت اختیاری با دنباله‌های گریز نوشت: \fB\ea\fR برای زنگ (bell)، \fB\eb\fR برای پس‌بر (backspace)، \fB\ef\fR برای برگه‌خور (form feed)، \fB\en\fR برای سطر جدید (line feed)، \fB\er\fR برای بازگشت به ابتدای سطر (carriage return)، \fB\et\fR برای تب افقی، و \fB\ev\fR برای تب عمودی\&. هر بایتی را می‌توان با کدهای اکتال ۳ رقمی نوشت (مانند \fB\e033\fR)\&. تمام نام‌های فایل را می‌توان به صورت رشته‌های نقل‌قول‌شده نمایش داد\&.
.sp
یک \fI<path>\fR باید از جداکننده‌های دایرکتوری به سبک یونیکس (اسلش رو به جلو \fB/\fR) استفاده کند و مقدار آن باید به شکل متعارف (canonical) باشد\&. به این معنی که نباید:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
شامل یک بخش دایرکتوری خالی باشد (برای مثال
\fBfoo//bar\fR
نامعتبر است)،
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
با یک جداکننده دایرکتوری خاتمه یابد (برای مثال
\fBfoo/\fR
نامعتبر است)،
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
با یک جداکننده دایرکتوری آغاز شود (برای مثال
\fB/foo\fR
نامعتبر است)،
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
شامل مؤلفه ویژه \&. یا \&.\&. باشد (برای مثال
\fBfoo/\&./bar\fR
و
\fBfoo/\fR\fB\&.\&.\fR\fB/bar\fR
نامعتبر هستند)\&.
.RE
.sp
ریشه درخت را می‌توان با یک رشته خالی به عنوان \fI<path>\fR نمایش داد\&.
.sp
یک \fI<path>\fR نمی‌تواند شامل NUL باشد، چه به صورت لفظی و چه به صورت گریزیافته مانند \fB\e000\fR\&. توصیه می‌شود که \fI<path>\fR همواره با استفاده از UTF\-8 کدگذاری شود\&.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBfiledelete\fR
.RS 4
.sp
در یک دستور \fBcommit\fR برای حذف یک فایل یا حذف بازگشتی یک دایرکتوری کامل از شاخه گنجانده می‌شود\&. چنانچه حذف فایل یا دایرکتوری موجب خالی شدن دایرکتوری والد آن شود، دایرکتوری والد نیز به‌طور خودکار حذف خواهد شد\&. این فرایند به‌صورت آبشاری در ساختار درختی به سمت بالا ادامه می‌یابد تا به نخستین دایرکتوری غیرخالی یا به ریشه برسد\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(AqD\*(Aq SP <path> LF
.fi
.if n \{\
.RE
.\}
.sp
در اینجا \fI<path>\fR مسیر کامل فایل یا زیردایرکتوری است که باید از شاخه حذف شود\&. برای شرح تفصیلی \fI<path>\fR، به \fBfilemodify\fR در بالا مراجعه کنید\&.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBfilecopy\fR
.RS 4
.sp
یک فایل یا زیردایرکتوری موجود را به‌صورت بازگشتی به مکانی دیگر درون شاخه رونوشت (کپی) می‌کند\&. فایل یا دایرکتوری مبدأ باید از قبل وجود داشته باشد\&. اگر مقصد وجود داشته باشد، محتوای رونوشت‌شده از مبدأ به‌طور کامل جایگزین آن خواهد شد\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(AqC\*(Aq SP <path> SP <path> LF
.fi
.if n \{\
.RE
.\}
.sp
در اینجا نخستین \fI<path>\fR مکان مبدأ و دومین \fI<path>\fR مقصد است\&. برای شرح تفصیلی آنچه که \fI<path>\fR می‌تواند باشد، به \fBfilemodify\fR در بالا مراجعه کنید\&. برای استفاده از مسیر مبدأیی که حاوی فاصله (SP) است، مسیر باید در علامت نقل‌قول قرار گیرد\&.
.sp
دستور \fBfilecopy\fR بلافاصله اعمال می‌شود\&. پس از رونوشت مکان مبدأ به مقصد، هر دستور دیگری که در ادامه روی مکان مبدأ اعمال شود، هیچ تأثیری بر مقصد رونوشت نخواهد داشت\&.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBfilerename\fR
.RS 4
.sp
نام یک فایل یا زیردایرکتوری موجود را تغییر داده و به مکانی دیگر درون شاخه منتقل می‌کند\&. فایل یا دایرکتوری مبدأ باید از قبل وجود داشته باشد\&. اگر مقصد وجود داشته باشد، با دایرکتوری مبدأ جایگزین خواهد شد\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(AqR\*(Aq SP <path> SP <path> LF
.fi
.if n \{\
.RE
.\}
.sp
در اینجا نخستین \fI<path>\fR مکان مبدأ و دومین \fI<path>\fR مقصد است\&. برای شرح تفصیلی آنچه که \fI<path>\fR می‌تواند باشد، به \fBfilemodify\fR در بالا مراجعه کنید\&. برای استفاده از مسیر مبدأیی که حاوی فاصله (SP) است، مسیر باید در علامت نقل‌قول قرار گیرد\&.
.sp
دستور \fBfilerename\fR بلافاصله اعمال می‌شود\&. پس از تغییر نام مکان مبدأ به مقصد، هر دستور دیگری که در ادامه روی مکان مبدأ اعمال شود فایل‌های جدیدی در آنجا ایجاد خواهد کرد و تأثیری بر مقصد تغییر نام نخواهد داشت\&.
.sp
توجه داشته باشید که \fBfilerename\fR همانند یک \fBfilecopy\fR و به دنبال آن یک \fBfiledelete\fR روی مکان مبدأ است\&. استفاده از \fBfilerename\fR مزیت عملکردی اندکی دارد، اما این مزیت به قدری ناچیز است که هرگز ارزش تلاش برای تبدیل یک جفت حذف/افزودن در محتوای مبدأ به تغییر نام را برای \fBfast\-import\fR ندارد\&. این دستور \fBfilerename\fR صرفاً برای سهولت فرانت‌آندهایی ارائه شده است که در حال حاضر اطلاعات تغییر نام را در اختیار دارند و نمی‌خواهند خود را با تجزیه آن به یک \fBfilecopy\fR و به دنبال آن یک \fBfiledelete\fR به زحمت بیندازند\&.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBfiledeleteall\fR
.RS 4
.sp
در یک دستور \fBcommit\fR برای حذف تمام فایل‌ها (و همچنین تمام دایرکتوری‌ها) از شاخه گنجانده می‌شود\&. این دستور ساختار داخلی شاخه را بازنشانی می‌کند تا هیچ فایلی درون آن نباشد، و به فرانت‌اند امکان می‌دهد که متعاقباً تمام فایل‌های مد نظر را از ابتدا اضافه کند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqdeleteall\*(Aq LF
.fi
.if n \{\
.RE
.\}
.sp
این دستور در صورتی بسیار مفید است که فرانت‌اند نداند (یا اهمیتی ندهد که بداند) در حال حاضر چه فایل‌هایی روی شاخه وجود دارند، و بنابراین نتواند دستورات مناسب \fBfiledelete\fR را برای به‌روزرسانی محتوا تولید کند\&.
.sp
صادر کردن یک دستور \fBfiledeleteall\fR و به دنبال آن دستورات لازم \fBfilemodify\fR برای تنظیم محتوای صحیح، همان نتایجی را ایجاد می‌کند که ارسال صرفاً دستورات مورد نیاز \fBfilemodify\fR و \fBfiledelete\fR به همراه دارد\&. با این حال، رویکرد \fBfiledeleteall\fR ممکن است \fBfast\-import\fR را وادار کند به ازای هر شاخه فعال حافظه کمی بیشتر (کمتر از ۱ مبی‌بایت حتی برای اکثر پروژه‌های بزرگ) مصرف کند؛ بنابراین به فرانت‌آندهایی که می‌توانند به‌راحتی فقط مسیرهای تحت تأثیر یک کامیت را به دست آورند، توصیه می‌شود که از آن روش استفاده کنند\&.
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBnotemodify\fR
.RS 4
.sp
در یک دستور \fBcommit\fR \fI<notes\-ref>\fR برای افزودن یک یادداشت جدید جهت حاشیه‌نویسی یک \fI<commit\-ish>\fR یا تغییر محتوای این حاشیه‌نویسی گنجانده می‌شود\&. از نظر داخلی، این دستور مشابه \fBfilemodify 100644\fR روی مسیر \fI<commit\-ish>\fR است (که ممکن است به زیردایرکتوری‌هایی تقسیم شود)\&. توصیه نمی‌شود از هیچ دستور دیگری برای نوشتن روی درخت \fI<notes\-ref>\fR استفاده کنید مگر \fBfiledeleteall\fR برای حذف تمام یادداشت‌های موجود در این درخت\&. این دستور دو شیوه متفاوت برای مشخص کردن محتوای یادداشت دارد\&.
.PP
قالب داده خارجی
.RS 4
محتوای داده برای یادداشت از قبل توسط یک دستور پیشین
\fBblob\fR
تأمین شده است\&. فرانت‌اند تنها باید آن را به کامیتی که قرار است حاشیه‌نویسی شود متصل کند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(AqN\*(Aq SP <dataref> SP <commit\-ish> LF
.fi
.if n \{\
.RE
.\}
.sp
در اینجا
\fI<dataref>\fR
می‌تواند یک ارجاع نشانگر (\fB:\fR\fI<idnum>\fR) باشد که توسط یک دستور پیشین
\fBblob\fR
تنظیم شده است، یا یک هش کامل ۴۰ بایتی SHA\-1 از یک شیء بلاب موجود در گیت\&.
.RE
.PP
قالب داده درون‌خطی
.RS 4
محتوای داده برای یادداشت هنوز تأمین نشده است\&. فرانت‌اند می‌خواهد آن را به عنوان بخشی از این دستور تغییر ارائه دهد\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(AqN\*(Aq SP \*(Aqinline\*(Aq SP <commit\-ish> LF
        data
.fi
.if n \{\
.RE
.\}
.sp
برای شرح تفصیلی دستور
\fBdata\fR
به پایین مراجعه کنید\&.
.RE
.sp
در هر دو قالب، \fI<commit\-ish>\fR هر یک از عبارات مشخص‌کننده کامیت است که توسط \fBfrom\fR نیز پذیرفته می‌شود (به بالا مراجعه کنید)\&.
.RE
.SS "\fBmark\fR"
.sp
ترتیبی می‌دهد تا fast\-import ارجاعی به شیء فعلی را ذخیره کند، و به فرانت‌اند اجازه می‌دهد در آینده بدون دانستن SHA\-1 این شیء، آن را فراخوانی کند\&. در اینجا شیء فعلی همان دستور ایجاد شیئی است که دستور \fBmark\fR درون آن ظاهر شده است\&. این شیء می‌تواند \fBcommit\fR، \fBtag\fR، و \fBblob\fR باشد، اما \fBcommit\fR رایج‌ترین مورد استفاده است\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqmark\*(Aq SP \*(Aq:\*(Aq <idnum> LF
.fi
.if n \{\
.RE
.\}
.sp
که در آن \fI<idnum>\fR عددی است که توسط فرانت‌اند به این نشان (mark) اختصاص داده شده است\&. مقدار \fI<idnum>\fR به صورت یک عدد صحیح دهدهی ASCII بیان می‌شود\&. مقدار 0 رزرو شده است و نمی‌تواند به عنوان یک نشان استفاده شود\&. تنها مقادیر بزرگ‌تر یا مساوی با 1 می‌توانند به عنوان نشان استفاده شوند\&.
.sp
نشان‌های جدید به طور خودکار ایجاد می‌شوند\&. نشان‌های موجود را می‌توان به سادگی با استفاده مجدد از همان \fI<idnum>\fR در یک دستور \fBmark\fR دیگر، به شیء دیگری منتقل کرد\&.
.SS "\fBoriginal\-oid\fR"
.sp
نام شیء در سامانه کنترل نسخهٔ اصلی را ارائه می‌دهد\&. ابزار fast\-import به سادگی این دستورالعمل را نادیده می‌گیرد، اما فرایندهای پالایشی (فیلتر) که پیش از ارسال به fast\-import روی جریان داده کار کرده و آن را اصلاح می‌کنند، ممکن است از این اطلاعات بهره ببرند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqoriginal\-oid\*(Aq SP <object\-identifier> LF
.fi
.if n \{\
.RE
.\}
.sp
که در آن \fI<object\-identifier>\fR هر رشته‌ای است که شامل LF نباشد\&.
.SS "\fBtag\fR"
.sp
یک برچسب یادداشت‌دار با ارجاع به یک کامیت مشخص ایجاد می‌کند\&. برای ایجاد برچسب‌های سبک (غیر یادداشت‌دار)، دستور \fBreset\fR در زیر را ببینید\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqtag\*(Aq SP <name> LF
        mark?
        \*(Aqfrom\*(Aq SP <commit\-ish> LF
        original\-oid?
        \*(Aqtagger\*(Aq (SP <name>)? SP LT <email> GT SP <when> LF
        data
.fi
.if n \{\
.RE
.\}
.sp
که در آن \fI<name>\fR نام برچسبی است که باید ایجاد شود\&.
.sp
نام‌های برچسب هنگام ذخیره در گیت به طور خودکار با پیشوند \fBrefs/tags/\fR ذخیره می‌شوند، بنابراین وارد کردن نماد شاخه CVS به نام \fBRELENG\-1_0\-FINAL\fR فقط از \fBRELENG\-1_0\-FINAL\fR برای \fI<name>\fR استفاده می‌کند، و fast\-import ارجاع متناظر را به صورت \fBrefs/tags/RELENG\-1_0\-FINAL\fR می‌نویسد\&.
.sp
مقدار \fI<name>\fR باید یک refname معتبر در گیت باشد و بنابراین ممکن است شامل اسلش روبه‌جلو (forward slash) باشد\&. از آنجا که \fBLF\fR در یک refname گیت معتبر نیست، هیچ نحو نقل‌قول یا گریزی در اینجا پشتیبانی نمی‌شود\&.
.sp
دستور \fBfrom\fR همانند دستور \fBcommit\fR است؛ برای جزئیات به بخش بالا مراجعه کنید\&.
.sp
دستور \fBtagger\fR از قالبی مشابه با \fBcommitter\fR در درون \fBcommit\fR استفاده می‌کند؛ مجدداً برای جزئیات به بخش بالا مراجعه کنید\&.
.sp
دستور \fBdata\fR پس از \fBtagger\fR باید پیام برچسب یادداشت‌دار را فراهم کند (برای نحو دستور \fBdata\fR به بخش زیر مراجعه کنید)\&. برای وارد کردن پیام برچسب خالی از داده‌ای با طول 0 استفاده کنید\&. پیام‌های برچسب قالب آزاد دارند و توسط گیت تفسیر نمی‌شوند\&. در حال حاضر آن‌ها باید با کدگذاری UTF\-8 کدبندی شوند، زیرا fast\-import اجازه تعیین سایر کدگذاری‌ها را نمی‌دهد\&.
.sp
امضای برچسب‌های یادداشت‌دار در حین واردسازی از درون fast\-import پشتیبانی نمی‌شود\&. تلاش برای گنجاندن امضای PGP/GPG خودتان توصیه نمی‌شود، زیرا فرانت‌اند (به سادگی) به مجموعه کامل بایت‌هایی که معمولاً در چنین امضایی قرار می‌گیرند دسترسی ندارد\&. اگر امضا کردن لازم است، برچسب‌های سبک را از درون fast\-import با استفاده از \fBreset\fR ایجاد کنید، سپس نسخه‌های یادداشت‌دار آن برچسب‌ها را به صورت برون‌خط (آفلاین) با فرایند استاندارد \fIgit tag\fR ایجاد کنید\&.
.SS "\fBreset\fR"
.sp
شاخهٔ نام‌گذاری‌شده را ایجاد (یا بازسازی) می‌کند، که به صورت اختیاری از یک بازنگری (revision) خاص شروع می‌شود\&. دستور reset به فرانت‌اند امکان می‌دهد یک دستور \fBfrom\fR جدید را برای یک شاخهٔ موجود صادر کند، یا یک شاخه جدید از یک کامیت موجود بدون ایجاد یک کامیت جدید بسازد\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqreset\*(Aq SP <ref> LF
        (\*(Aqfrom\*(Aq SP <commit\-ish> LF)?
        LF?
.fi
.if n \{\
.RE
.\}
.sp
برای توضیحات تفصیلی درباره \fI<ref>\fR و \fI<commit\-ish>\fR، بخش بالا تحت عنوان \fBcommit\fR و \fBfrom\fR را ببینید\&.
.sp
نویسه \fBLF\fR پس از دستور اختیاری است (قبلاً الزامی بود)\&.
.sp
دستور \fBreset\fR همچنین می‌تواند برای ایجاد برچسب‌های سبک (غیر یادداشت‌دار) استفاده شود\&. برای نمونه:
.sp
.if n \{\
.RS 4
.\}
.nf
reset refs/tags/938
from :938
.fi
.if n \{\
.RE
.\}
.sp
برچسب سبک \fBrefs/tags/938\fR را ایجاد می‌کند که به هر کامیتی ارجاع دارد که نشان \fB:938\fR به آن اشاره می‌کند\&.
.SS "\fBblob\fR"
.sp
درخواست نوشتن یک بازنگری فایل در packfile را می‌دهد\&. این بازنگری به هیچ کامیتی متصل نیست؛ این اتصال باید در دستور بعدی \fBcommit\fR با ارجاع به blob از طریق یک نشان اختصاص‌یافته برقرار شود\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqblob\*(Aq LF
        mark?
        original\-oid?
        data
.fi
.if n \{\
.RE
.\}
.sp
دستور mark در اینجا اختیاری است چرا که برخی فرانت‌اندها تصمیم گرفته‌اند SHA\-1 گیت را برای blob خودشان تولید کنند و آن را مستقیماً به \fBcommit\fR تحویل دهند\&. با این حال این کار معمولاً زحمتی بیشتر از ارزشش دارد، چرا که ذخیره‌سازی نشان‌ها کم‌هزینه و استفاده از آن‌ها آسان است\&.
.SS "\fBdata\fR"
.sp
داده‌های خام (برای استفاده به عنوان محتوای blob/فایل، پیام‌های کامیت، یا پیام‌های برچسب یادداشت‌دار) را در اختیار fast\-import قرار می‌دهد\&. داده‌ها را می‌توان با استفاده از تعداد دقیق بایت یا با تحدید توسط یک خط پایانی ارائه کرد\&. فرانت‌آندهای واقعی که برای تبدیل‌های در سطح تولید (production) در نظر گرفته شده‌اند باید همیشه از قالب تعداد دقیق بایت استفاده کنند، زیرا این روش پایدارتر است و عملکرد بهتری دارد\&. قالب تحدیدشده عمدتاً برای آزمایش fast\-import در نظر گرفته شده است\&.
.sp
خطوط توضیحی که درون بخش \fI<raw>\fR از دستورات \fBdata\fR ظاهر می‌شوند، همواره به عنوان بخشی از بدنه داده در نظر گرفته می‌شوند و بنابراین هرگز توسط fast\-import نادیده گرفته نمی‌شوند\&. این ویژگی وارد کردن هرگونه محتوای فایل/پیامی را که خطوط آن ممکن است با # شروع شود، امن می‌سازد\&.
.PP
قالب تعداد دقیق بایت
.RS 4
فرانت‌اند باید تعداد بایت‌های داده را مشخص کند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqdata\*(Aq SP <count> LF
        <raw> LF?
.fi
.if n \{\
.RE
.\}
.sp
که در آن
\fI<count>\fR
تعداد دقیق بایت‌های ظاهرشده در درون
\fI<raw>\fR
است\&. مقدار
\fI<count>\fR
به صورت یک عدد صحیح دهدهی ASCII بیان می‌شود\&. نویسه
\fBLF\fR
در هر دو طرف
\fI<raw>\fR
در
\fI<count>\fR
محاسبه نمی‌شود و در داده‌های واردشده گنجانده نخواهد شد\&.
.sp
نویسه
\fBLF\fR
پس از
\fI<raw>\fR
اختیاری است (قبلاً الزامی بود) اما توصیه می‌شود\&. گنجاندن همیشگی آن، اشکال‌زدایی جریان fast\-import را آسان‌تر می‌کند زیرا دستور بعدی همیشه در ستون ۰ از خط بعدی آغاز می‌شود، حتی اگر
\fI<raw>\fR
با یک
\fBLF\fR
پایان نیافته باشد\&.
.RE
.PP
قالب تحدیدشده
.RS 4
از یک رشته جداکننده برای مشخص کردن پایان داده‌ها استفاده می‌شود\&. دستور fast\-import طول داده‌ها را با جستجو برای جداکننده محاسبه می‌کند\&. این قالب عمدتاً برای آزمایش مفید است و برای داده‌های واقعی توصیه نمی‌شود\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqdata\*(Aq SP \*(Aq<<\*(Aq <delim> LF
        <raw> LF
        <delim> LF
        LF?
.fi
.if n \{\
.RE
.\}
.sp
که در آن
\fI<delim>\fR
رشته جداکننده انتخاب‌شده است\&. رشته
\fI<delim>\fR
نباید به تنهایی در یک خط درون
\fI<raw>\fR
ظاهر شود، زیرا در غیر این صورت fast\-import تصور می‌کند که داده‌ها زودتر از آنچه در واقعیت است پایان یافته‌اند\&. نویسه
\fBLF\fR
بلافاصله پس از
\fI<raw>\fR
بخشی از
\fI<raw>\fR
است\&. این یکی از محدودیت‌های قالب تحدیدشده است؛ ارسال تکه داده‌ای که آخرین بایت آن LF نباشد، غیرممکن است\&.
.sp
نویسه
\fBLF\fR
پس از
\fI<delim>\fR
\fBLF\fR
اختیاری است (قبلاً الزامی بود)\&.
.RE
.SS "\fBalias\fR"
.sp
ثبت می‌کند که یک نشان به یک شیء معین ارجاع می‌دهد، بدون اینکه ابتدا شیء جدیدی ایجاد شود\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqalias\*(Aq LF
        mark
        \*(Aqto\*(Aq SP <commit\-ish> LF
        LF?
.fi
.if n \{\
.RE
.\}
.sp
برای توضیحات تفصیلی درباره \fI<commit\-ish>\fR، بخش بالا تحت عنوان \fBfrom\fR را ببینید\&.
.SS "\fBcheckpoint\fR"
.sp
دستور fast\-import را مجبور می‌کند تا packfile فعلی را ببندد، یک packfile جدید آغاز کند، و تمام ارجاع‌های شاخه، برچسب‌ها و نشان‌های فعلی را ذخیره نماید\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqcheckpoint\*(Aq LF
        LF?
.fi
.if n \{\
.RE
.\}
.sp
توجه داشته باشید که وقتی packfile فعلی به \-\-max\-pack\-size یا 4 GiB (هر کدام که محدودیت کمتری باشد) می‌رسد، fast\-import به طور خودکار packfile را تعویض می‌کند\&. در طول یک تعویض خودکار packfile، دستور fast\-import ارجاع‌های شاخه، برچسب‌ها یا نشان‌ها را به‌روزرسانی نمی‌کند\&.
.sp
از آنجا که یک \fBcheckpoint\fR می‌تواند به مقدار قابل توجهی زمان پردازنده (CPU) و ورودی/خروجی دیسک (برای محاسبه جمع کنترلی کلی SHA\-1 بسته، تولید فایل نمایه (index) متناظر، و به‌روزرسانی ارجاع‌ها) نیاز داشته باشد، تکمیل یک دستور \fBcheckpoint\fR منفرد می‌تواند به راحتی چندین دقیقه به طول بینجامد\&.
.sp
فرانت‌اندها ممکن است ترجیح دهند در طول واردسازی‌های بسیار بزرگ و طولانی، یا زمانی که نیاز دارند به یک فرایند گیت دیگر اجازه دسترسی به یک شاخه را بدهند، دستورهای checkpoint را صادر کنند\&. با این حال، با توجه به اینکه یک مخزن ۳۰ گیبی‌بایتی (30 GiB) از Subversion را می‌توان از طریق fast\-import در حدود ۳ ساعت در گیت بارگذاری کرد، ایجاد نقطه بازرسی (checkpointing) صریح ممکن است ضروری نباشد\&.
.sp
نویسه \fBLF\fR پس از دستور اختیاری است (قبلاً الزامی بود)\&.
.SS "\fBprogress\fR"
.sp
باعث می‌شود که fast\-import کل خط \fBprogress\fR را بدون تغییر در کانال خروجی استاندارد خود (توصیف‌کننده پرونده ۱) هنگامی که دستور از جریان ورودی پردازش می‌شود، چاپ کند\&. این دستور در غیر این صورت هیچ تأثیری بر درون‌ریزی فعلی یا هیچ‌یک از وضعیت‌های داخلی fast\-import ندارد\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqprogress\*(Aq SP <any> LF
        LF?
.fi
.if n \{\
.RE
.\}
.sp
بخش \fI<any>\fR از دستور می‌تواند شامل هر دنباله‌ای از بایت‌ها باشد که حاوی \fBLF\fR نباشد\&. نویسه \fBLF\fR پس از دستور اختیاری است\&. فراخوانندگان ممکن است بخواهند خروجی را از طریق ابزاری مانند sed پردازش کنند تا بخش آغازین خط حذف شود، برای مثال:
.sp
.if n \{\
.RS 4
.\}
.nf
frontend | git fast\-import | sed \*(Aqs/^progress //\*(Aq
.fi
.if n \{\
.RE
.\}
.sp
قرار دادن دستور \fBprogress\fR بلافاصله پس از یک \fBcheckpoint\fR به خواننده اطلاع می‌دهد که چه زمانی \fBcheckpoint\fR تکمیل شده است و می‌تواند با اطمینان به مراجعی (refs) که fast\-import به‌روزرسانی کرده دسترسی پیدا کند\&.
.SS "\fBget\-mark\fR"
.sp
باعث می‌شود که fast\-import مقدار SHA\-1 متناظر با یک نشان را در stdout یا در توصیف‌کننده پرونده‌ای که قبلاً با آرگومان \fB\-\-cat\-blob\-fd\fR تنظیم شده است، چاپ کند\&. این دستور در غیر این صورت هیچ تأثیری بر درون‌ریزی فعلی ندارد؛ هدف آن بازیابی SHA\-1هایی است که کامیت‌های بعدی ممکن است بخواهند در پیام‌های کامیت خود به آن‌ها ارجاع دهند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqget\-mark\*(Aq SP \*(Aq:\*(Aq <idnum> LF
.fi
.if n \{\
.RE
.\}
.sp
برای جزئیات درباره نحوه خواندن ایمن این خروجی، بخش \(lqپاسخ‌ها به دستورات (Responses To Commands)\(rq در ادامه را ببینید\&.
.SS "\fBcat\-blob\fR"
.sp
باعث می‌شود که fast\-import یک بلاب (blob) را در توصیف‌کننده پرونده‌ای که قبلاً با آرگومان \fB\-\-cat\-blob\-fd\fR تعیین شده است، چاپ کند\&. این دستور در غیر این صورت هیچ تأثیری بر درون‌ریزی فعلی ندارد؛ هدف اصلی آن بازیابی بلاب‌هایی است که ممکن است در حافظه fast\-import باشند اما از مخزن مقصد قابل دسترسی نباشند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqcat\-blob\*(Aq SP <dataref> LF
.fi
.if n \{\
.RE
.\}
.sp
مقدار \fI<dataref>\fR می‌تواند یک ارجاع نشان (\fB:\fR\fI<idnum>\fR) باشد که قبلاً تنظیم شده است، یا یک SHA\-1 کامل ۴۰ بایتی از یک شیء بلاب گیت باشد، چه از قبل موجود بوده و چه آماده نوشته شدن باشد\&.
.sp
خروجی از همان قالب \fBgit\fR \fBcat\-file\fR \fB\-\-batch\fR استفاده می‌کند:
.sp
.if n \{\
.RS 4
.\}
.nf
<sha1> SP \*(Aqblob\*(Aq SP <size> LF
<contents> LF
.fi
.if n \{\
.RE
.\}
.sp
این دستور می‌تواند در جایی که یک دستورالعمل \fBfilemodify\fR ظاهر می‌شود استفاده شود، که اجازه می‌دهد در میانه یک کامیت به کار رود\&. برای یک \fBfilemodify\fR با استفاده از یک دستورالعمل درون‌خطی، می‌تواند درست پیش از دستورالعمل \fBdata\fR نیز ظاهر شود\&.
.sp
برای جزئیات درباره نحوه خواندن ایمن این خروجی، بخش \(lqپاسخ‌ها به دستورات (Responses To Commands)\(rq در ادامه را ببینید\&.
.SS "\fBls\fR"
.sp
اطلاعات مربوط به شیء موجود در یک مسیر را در توصیف‌کننده پرونده‌ای که قبلاً با آرگومان \fB\-\-cat\-blob\-fd\fR تعیین شده است، چاپ می‌کند\&. این امر چاپ یک بلاب از کامیت فعال (با \fBcat\-blob\fR) یا نسخه‌برداری از یک بلاب یا درخت از کامیت قبلی برای استفاده در کامیت فعلی (با \fBfilemodify\fR) را امکان‌پذیر می‌سازد\&.
.sp
دستور \fBls\fR همچنین می‌تواند در جایی که یک دستورالعمل \fBfilemodify\fR ظاهر می‌شود استفاده شود، که اجازه می‌دهد در میانه یک کامیت به کار رود\&.
.PP
خواندن از کامیت فعال
.RS 4
این شکل تنها می‌تواند در میانه یک
\fBcommit\fR
استفاده شود\&. مسیر، یک مدخل دایرکتوری در کامیت فعال fast\-import را نام‌گذاری می‌کند\&. مسیر در این حالت باید در گیومه قرار گیرد\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqls\*(Aq SP <path> LF
.fi
.if n \{\
.RE
.\}
.RE
.PP
خواندن از یک درخت نام‌گذاری‌شده
.RS 4
مقدار
\fI<dataref>\fR
می‌تواند یک ارجاع نشان (\fB:\fR\fI<idnum>\fR) یا یک SHA\-1 کامل ۴۰ بایتی از یک شیء برچسب، کامیت یا درخت گیت باشد، چه از قبل موجود باشد و چه در انتظار نوشته شدن باشد\&. مسیر، نسبت به بالاترین سطح درختی که با
\fI<dataref>\fR
نام‌گذاری شده است، سنجیده می‌شود\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqls\*(Aq SP <dataref> SP <path> LF
.fi
.if n \{\
.RE
.\}
.RE
.sp
برای شرح مفصل \fI<path>\fR، دستور \fBfilemodify\fR در بالا را ببینید\&.
.sp
خروجی از همان قالب \fBgit\fR \fBls\-tree\fR \fI<tree>\fR \fB\-\-\fR \fI<path>\fR استفاده می‌کند:
.sp
.if n \{\
.RS 4
.\}
.nf
<mode> SP (\*(Aqblob\*(Aq | \*(Aqtree\*(Aq | \*(Aqcommit\*(Aq) SP <dataref> HT <path> LF
.fi
.if n \{\
.RE
.\}
.sp
مقدار <dataref> نمایانگر شیء بلاب، درخت یا کامیت در <path> است و می‌تواند در دستورات بعدی \fIget\-mark\fR، \fIcat\-blob\fR، \fIfilemodify\fR یا \fIls\fR استفاده شود\&.
.sp
اگر هیچ فایل یا زیردرختی در آن مسیر وجود نداشته باشد، \fIgit fast\-import\fR در عوض گزارش می‌دهد:
.sp
.if n \{\
.RS 4
.\}
.nf
missing SP <path> LF
.fi
.if n \{\
.RE
.\}
.sp
برای جزئیات درباره نحوه خواندن ایمن این خروجی، بخش \(lqپاسخ‌ها به دستورات (Responses To Commands)\(rq در ادامه را ببینید\&.
.SS "\fBfeature\fR"
.sp
الزام می‌کند که fast\-import از ویژگی مشخص‌شده پشتیبانی کند، وگرنه عملیات را لغو (abort) می‌کند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
        \*(Aqfeature\*(Aq SP <feature> (\*(Aq=\*(Aq <argument>)? LF
.fi
.if n \{\
.RE
.\}
.sp
بخش <feature> از دستور می‌تواند هر یک از موارد زیر باشد:
.PP
date\-format, export\-marks, relative\-marks, no\-relative\-marks, force
.RS 4
طوری عمل می‌کند که گویی گزینه خط فرمان متناظر با پیشوند
\fB\-\-\fR
در خط فرمان ارسال شده است (بخش گزینه‌ها (OPTIONS) در بالا را ببینید)\&.
.RE
.PP
import\-marks, import\-marks\-if\-exists
.RS 4
مشابه \-\-import\-marks به جز در سه جنبه: نخست، تنها یک دستور "feature import\-marks" یا "feature import\-marks\-if\-exists" در هر جریان مجاز است؛ دوم، گزینه خط فرمان \-\-import\-marks= یا \-\-import\-marks\-if\-exists بر هر یک از این دستورات "feature" در جریان اولویت دارد؛ سوم، "feature import\-marks\-if\-exists" همانند گزینه خط فرمان متناظر، فایلی را که وجود ندارد بدون ایجاد خطا نادیده می‌گیرد\&.
.RE
.PP
get\-mark, cat\-blob, ls
.RS 4
الزام می‌کند که بک‌اند به‌ترتیب از دستور
\fIget\-mark\fR،
\fIcat\-blob\fR یا
\fIls\fR
پشتیبانی کند\&. نسخه‌هایی از fast\-import که از دستور مشخص‌شده پشتیبانی نمی‌کنند، با پیامی که این موضوع را نشان می‌دهد خارج خواهند شد\&. این امر اجازه می‌دهد که عملیات درون‌ریزی خیلی زود با یک پیام روشن خطا دهد، نه اینکه پیش از شناسایی دستور پشتیبانی‌نشده، زمان روی بخش آغازین یک درون‌ریزی تلف شود\&.
.RE
.PP
notes
.RS 4
الزام می‌کند که بک‌اند از زیردستور
\fInotemodify\fR
(N) برای دستور
\fIcommit\fR
پشتیبانی کند\&. نسخه‌هایی از fast\-import که از یادداشت‌ها (notes) پشتیبانی نمی‌کنند، با پیامی که این موضوع را نشان می‌دهد خارج خواهند شد\&.
.RE
.PP
done
.RS 4
اگر جریان بدون یک دستور
\fIdone\fR
پایان یابد، با خطا خارج می‌شود\&. بدون این ویژگی، خطاهایی که باعث می‌شوند فرانت‌اند به‌طور ناگهانی در نقطه‌ای مناسب در جریان متوقف شود ممکن است شناسایی نشوند\&. این ممکن است برای مثال زمانی رخ دهد که یک فرانت‌اندِ درون‌ریزی در میانه عملیات بدون ارسال سیگنال SIGTERM یا SIGKILL به فرآیند زیردست git fast\-import خود متوقف شود (بمیرد)\&.
.RE
.SS "\fBoption\fR"
.sp
گزینه مشخص‌شده را طوری پردازش می‌کند که git fast\-import مطابق با نیازهای فرانت‌اند رفتار کند\&. توجه داشته باشید گزینه‌هایی که توسط فرانت‌اند مشخص می‌شوند، با هر گزینه‌ای که کاربر ممکن است به خودِ git fast\-import ارسال کند لغو و بازنویسی می‌شوند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
    \*(Aqoption\*(Aq SP <option> LF
.fi
.if n \{\
.RE
.\}
.sp
بخش \fI<option>\fR از دستور می‌تواند شامل هر یک از گزینه‌های فهرست‌شده در بخش OPTIONS باشد که معناشناسی درون‌ریزی را تغییر نمی‌دهند، بدون پیشوند \fB\-\-\fR، و به همان شیوه با آن رفتار می‌شود\&.
.sp
دستورات option باید نخستین دستورات در ورودی باشند (بدون در نظر گرفتن دستورات feature)؛ فرستادن یک دستور option پس از هر دستور غیر از گزینه یک خطا است\&.
.sp
گزینه‌های خط فرمان زیر، معناشناسی درون‌ریزی را تغییر می‌دهند و بنابراین نباید به عنوان option فرستاده شوند:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
date\-format
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
import\-marks
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
export\-marks
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
cat\-blob\-fd
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
force
.RE
.SS "\fBdone\fR"
.sp
اگر ویژگی \fBdone\fR در حال استفاده نباشد، طوری رفتار می‌شود که گویی EOF خوانده شده است\&. این می‌تواند برای آگاه ساختن fast\-import به پایان زودهنگام استفاده شود\&.
.sp
اگر گزینه خط فرمان \fB\-\-done\fR یا دستور \fBfeature\fR \fBdone\fR در حال استفاده باشد، دستور \fBdone\fR الزامی است و نشان‌دهنده پایان جریان است\&.
.SH "پاسخ‌ها به دستورات (RESPONSES TO COMMANDS)"
.sp
اشیاء جدید نوشته‌شده توسط fast\-import فوراً در دسترس نیستند\&. بیشتر دستورات fast\-import تا نقطه بررسی (یا تکمیل) بعدی، هیچ تأثیر قابل‌مشاهده‌ای ندارند\&. فرانت‌اند می‌تواند بدون نگرانی از اینکه دستورات با چه سرعتی اعمال می‌شوند، آن‌ها را برای پر کردن لوله ورودی fast\-import ارسال کند که با ساده‌سازی زمان‌بندی، کارایی را بهبود می‌بخشد\&.
.sp
با این حال، برای برخی از فرانت‌اندها، خواندن مجدد داده‌ها از مخزن فعلی هم‌زمان با به‌روزرسانی آن مفید است (برای نمونه زمانی که محتوای منبع، اشیاء را بر اساس وصله‌هایی توصیف می‌کند که باید بر روی اشیاء واردشده پیشین اعمال شوند)\&. این کار را می‌توان با اتصال فرانت‌اند و fast\-import از طریق لوله‌های دوطرفه انجام داد:
.sp
.if n \{\
.RS 4
.\}
.nf
mkfifo fast\-import\-output
frontend <fast\-import\-output |
git fast\-import >fast\-import\-output
.fi
.if n \{\
.RE
.\}
.sp
فرانت‌اَندی که بدین صورت راه‌اندازی شده است، می‌تواند از دستورات \fBprogress\fR، \fBget\-mark\fR، \fBls\fR و \fBcat\-blob\fR برای خواندن اطلاعات از فرآیند واردسازیِ در حال انجام استفاده کند\&.
.sp
برای جلوگیری از بن‌بست (deadlock)، چنین فرانت‌اندهایی باید پیش از انجام عملیات نوشتن در fast\-import که ممکن است مسدودکننده (blocking) باشند، تمام خروجی‌های معلقِ \fBprogress\fR، \fBls\fR، \fBget\-mark\fR و \fBcat\-blob\fR را به‌طور کامل مصرف کنند (بخوانند)\&.
.SH "گزارش‌های خرابی (CRASH REPORTS)"
.sp
چنانچه ورودی نامعتبری به fast\-import داده شود، با یک وضعیت خروج غیرصفر خاتمه می‌یابد و یک گزارش خرابی در بالاترین سطح مخزن گیت که در حال واردسازی به آن بود ایجاد می‌کند\&. گزارش‌های خرابی شامل یک تصویر لحظه‌ای (snapshot) از وضعیت داخلی fast\-import و همچنین تازه‌ترین دستوراتی هستند که منجر به خرابی شده‌اند\&.
.sp
تمام دستورات اخیر (شامل توضیحات جریان، تغییرات فایل و دستورات پیشرفت) در تاریخچه دستورات درون گزارش خرابی نمایش داده می‌شوند، اما داده‌های خام فایل و پیام‌های کامیت از گزارش خرابی مستثنی هستند\&. این حذف و استثنا در فضای فایل گزارش صرفه‌جویی می‌کند و مقدار بافرینگی را که fast\-import باید در حین اجرا انجام دهد کاهش می‌دهد\&.
.sp
پس از نوشتن یک گزارش خرابی، fast\-import بستهِ بسته‌بندی (packfile) فعلی را می‌بندد و جدول نشان‌ها (marks table) را صادر می‌کند\&. این امر به توسعه‌دهنده فرانت‌اند اجازه می‌دهد تا وضعیت مخزن را بررسی کرده و واردسازی را از نقطه‌ای که دچار خرابی شده از سر بگیرد\&. شاخه‌ها و برچسب‌های تغییریافته در حین خرابی به‌روزرسانی نمی‌شوند، زیرا واردسازی با موفقیت پایان نیافته است\&. اطلاعات شاخه و برچسب را می‌توان در گزارش خرابی یافت و در صورت نیاز به به‌روزرسانی، باید به‌صورت دستی اعمال شوند\&.
.sp
یک نمونه خرابی:
.sp
.if n \{\
.RS 4
.\}
.nf
$ cat >in <<END_OF_INPUT
# my very first test commit
commit refs/heads/master
committer Shawn O\&. Pearce <spearce> 19283 \-0400
# who is that guy anyway?
data <<EOF
this is my commit
EOF
M 644 inline \&.gitignore
data <<EOF
\&.gitignore
EOF
M 777 inline bob
END_OF_INPUT
.fi
.if n \{\
.RE
.\}
.sp
.if n \{\
.RS 4
.\}
.nf
$ git fast\-import <in
fatal: Corrupt mode: M 777 inline bob
fast\-import: dumping crash report to \&.git/fast_import_crash_8434
.fi
.if n \{\
.RE
.\}
.sp
.if n \{\
.RS 4
.\}
.nf
$ cat \&.git/fast_import_crash_8434
fast\-import crash report:
    fast\-import process: 8434
    parent process     : 1391
    at Sat Sep 1 00:58:12 2007
.fi
.if n \{\
.RE
.\}
.sp
.if n \{\
.RS 4
.\}
.nf
fatal: Corrupt mode: M 777 inline bob
.fi
.if n \{\
.RE
.\}
.sp
.if n \{\
.RS 4
.\}
.nf
Most Recent Commands Before Crash
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
  # my very first test commit
  commit refs/heads/master
  committer Shawn O\&. Pearce <spearce> 19283 \-0400
  # who is that guy anyway?
  data <<EOF
  M 644 inline \&.gitignore
  data <<EOF
* M 777 inline bob
.fi
.if n \{\
.RE
.\}
.sp
.if n \{\
.RS 4
.\}
.nf
Active Branch LRU
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
    active_branches = 1 cur, 5 max
.fi
.if n \{\
.RE
.\}
.sp
.if n \{\
.RS 4
.\}
.nf
pos  clock name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 1)      0 refs/heads/master
.fi
.if n \{\
.RE
.\}
.sp
.if n \{\
.RS 4
.\}
.nf
Inactive Branches
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
refs/heads/master:
  status      : active loaded dirty
  tip commit  : 0000000000000000000000000000000000000000
  old tree    : 0000000000000000000000000000000000000000
  cur tree    : 0000000000000000000000000000000000000000
  commit clock: 0
  last pack   :
.fi
.if n \{\
.RE
.\}
.sp
.if n \{\
.RS 4
.\}
.nf
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
END OF CRASH REPORT
.fi
.if n \{\
.RE
.\}
.SH "نکات و ترفندها (TIPS AND TRICKS)"
.sp
نکات و ترفندهای زیر از کاربران گوناگون fast\-import گردآوری شده‌اند و در اینجا به عنوان پیشنهاد ارائه می‌شوند\&.
.SS "استفاده از یک نشان در هر کامیت (Use One Mark Per Commit)"
.sp
هنگام انجام تبدیل یک مخزن، به ازای هر کامیت از یک نشان یکتا (\fBmark\fR \fB:\fR\fI<n>\fR) استفاده کرده و گزینه \-\-export\-marks را در خط فرمان مشخص کنید\&. fast\-import فایلی را تخلیه (dump) خواهد کرد که هر نشان و شناسه شیء SHA\-1 گیت مربوط به آن را فهرست می‌کند\&. اگر فرانت‌اند بتواند نشان‌ها را مجدداً به مخزن مبدأ پیوند دهد، با مقایسه هر کامیت گیت با بازبینی متناظر در مبدأ، بررسی صحت و کامل بودن واردسازی آسان خواهد بود\&.
.sp
هنگام انتقال از سامانه‌ای مانند Perforce یا Subversion، این کار باید بسیار ساده باشد، چرا که نشان fast\-import می‌تواند همان شماره مجموعه‌تغییرات (changeset) در Perforce یا شماره بازبینی در Subversion باشد\&.
.SS "جابه‌جایی آزادانه میان شاخه‌ها (Freely Skip Around Branches)"
.sp
لازم نیست تلاش کنید فرانت‌اند را به گونه‌ای بهینه‌سازی کنید که در طول واردسازی در هر زمان فقط به یک شاخه محدود بماند\&. اگرچه ممکن است این کار برای fast\-import اندکی سریع‌تر باشد، اما پیچیدگی کد فرانت‌اند را به میزان قابل توجهی افزایش می‌دهد\&.
.sp
سازوکار درونی LRU شاخه‌ها در fast\-import معمولاً بسیار خوب عمل می‌کند، و هزینه فعال‌سازی یک شاخه غیرفعال آن‌قدر پایین است که جابه‌جایی پی‌درپی میان شاخه‌ها عملاً هیچ تأثیری بر کارایی واردسازی ندارد\&.
.SS "مدیریت تغییر نام‌ها (Handling Renames)"
.sp
هنگام وارد کردن یک فایل یا دایرکتوری تغییرنام‌یافته، به‌سادگی نام(های) قدیمی را حذف کرده و نام(های) جدید را در طول کامیت متناظر اصلاح کنید\&. گیت تشخیص تغییر نام را پس از واقعه (after\-the\-fact) انجام می‌دهد، نه به صورت صریح در حین یک کامیت\&.
.SS "استفاده از شاخه‌های اصلاح برچسب (Use Tag Fixup Branches)"
.sp
برخی دیگر از سامانه‌های SCM به کاربر اجازه می‌دهند برچسبی از چندین فایل که متعلق به یک کامیت/مجموعه‌تغییرات یکسان نیستند ایجاد کند\&. یا برچسب‌هایی بسازد که زیرمجموعه‌ای از فایل‌های موجود در مخزن باشند\&.
.sp
وارد کردن این برچسب‌ها به همان صورت در گیت، بدون ایجاد دست‌کم یک کامیت که فایل‌ها را برای مطابقت با محتوای برچسب \(lqاصلاح\(rq (fixes up) کند، غیرممکن است\&. از دستور \fBreset\fR در fast\-import برای بازنشانی یک شاخه ساختگی (dummy) خارج از فضای شاخه‌های عادی خود به کامیت پایه برای برچسب استفاده کنید، سپس یک یا چند کامیت اصلاح فایل را ثبت کرده و در نهایت شاخه ساختگی را برچسب‌گذاری نمایید\&.
.sp
برای نمونه، از آنجا که تمام شاخه‌های عادی تحت \fBrefs/heads/\fR ذخیره می‌شوند، نام شاخه اصلاح برچسب را \fBTAG_FIXUP\fR بگذارید\&. بدین ترتیب غیرممکن است که شاخه اصلاحِ مورد استفاده واردکننده، تداخل فضای نام با شاخه‌های واقعیِ واردشده از مبدأ پیدا کند (نام \fBTAG_FIXUP\fR متمایز از \fBrefs/heads/TAG_FIXUP\fR است)\&.
.sp
هنگام ثبت کامیت‌های اصلاحی، استفاده از \fBmerge\fR را برای پیوند دادن کامیت(هایی) که بازبینی‌های فایل را برای شاخه اصلاح تأمین می‌کنند در نظر داشته باشید\&. انجام این کار به ابزارهایی مانند \fIgit blame\fR امکان می‌دهد تا در تاریخچه واقعی کامیت‌ها ردگیری کنند و فایل‌های مبدأ را به‌درستی حاشیه‌نویسی نمایند\&.
.sp
پس از پایان کار fast\-import، فرانت‌اند باید برای حذف شاخه ساختگی دستور \fBrm\fR \fB\&.git/TAG_FIXUP\fR را اجرا کند\&.
.SS "اکنون وارد کنید، بعداً مجدداً بسته‌بندی کنید (Import Now, Repack Later)"
.sp
به محض اتمام کار fast\-import، مخزن گیت کاملاً معتبر و آماده استفاده است\&. به‌طور معمول این کار حتی برای پروژه‌های بسیار بزرگ (بیش از ۱۰۰٬۰۰۰ کامیت) تنها زمان بسیار کوتاهی می‌برد\&.
.sp
با این حال، بسته‌بندی مجدد (repacking) مخزن برای بهبود محلی‌سازی داده‌ها (data locality) و کارایی دسترسی ضروری است\&. این فرآیند همچنین در پروژه‌های بسیار بزرگ می‌تواند ساعت‌ها طول بکشد (به‌ویژه اگر از گزینه \-f و یک پارامتر بزرگ \-\-window استفاده شود)\&. از آنجا که اجرای بسته‌بندی مجدد هم‌زمان با خوانندگان و نویسندگان ایمن است، بسته‌بندی مجدد را در پس‌زمینه اجرا کنید و بگذارید هر زمان کارش به پایان رسید تمام شود\&. هیچ دلیلی وجود ندارد که برای کاوش در پروژه گیت جدید خود منتظر بمانید!
.sp
اگر ترجیح می‌دهید منتظر بسته‌بندی مجدد بمانید، تا زمان تکمیل بسته‌بندی مجدد اقدام به اجرای معیارسنجی‌ها یا آزمون‌های کارایی نکنید\&. خروجی fast\-import فایل‌های بسته‌ای با بهینگی کمتر (suboptimal) است که اساساً هرگز در شرایط استفاده واقعی دیده نمی‌شوند\&.
.SS "بسته‌بندی مجدد داده‌های تاریخی (Repacking Historical Data)"
.sp
اگر داده‌های واردشده بسیار قدیمی (برای مثال قدیمی‌تر از سال گذشته) را مجدداً بسته‌بندی می‌کنید، صرف زمان اضافه برای پردازنده و ارائه گزینه \-\-window=50 (یا بیشتر) را هنگام اجرای \fIgit repack\fR در نظر داشته باشید\&. این کار زمان بیشتری می‌برد، اما فایل بسته کوچک‌تری نیز تولید خواهد کرد\&. شما تنها یک بار نیاز به صرف این تلاش دارید و هر کسی که از پروژه شما استفاده کند از مخزن کوچک‌تر بهره‌مند خواهد شد\&.
.SS "گنجاندن برخی پیام‌های پیشرفت (Include Some Progress Messages)"
.sp
هر از گاهی، ترتیبی دهید که فرانت‌اند شما یک پیام \fBprogress\fR به fast\-import بفرستد\&. محتوای پیام‌ها کاملاً آزاد و دلخواه است، بنابراین یک پیشنهاد می‌تواند این باشد که هر بار که تاریخ کامیت فعلی به ماه بعد می‌رود، ماه و سال جاری را خروجی دهد\&. کاربران شما با آگاهی از اینکه چه مقدار از جریان داده پردازش شده است، آسوده‌خاطرتر خواهند بود\&.
.SH "بهینه‌سازی فایل بسته (PACKFILE OPTIMIZATION)"
.sp
هنگام بسته‌بندی یک blob، همیشه fast\-import تلاش می‌کند تا نسبت به آخرین blob نوشته‌شده دلتاسازی (deltify) کند\&. مگر اینکه تمهید خاصی توسط فرانت‌اند اندیشیده شده باشد، این مورد احتمالاً نسخه قبلی همان فایل نخواهد بود؛ بنابراین دلتای ایجادشده کوچک‌ترین حالت ممکن نخواهد بود\&. فایل بسته حاصل فشرده خواهد شد، اما بهینه نخواهد بود\&.
.sp
فرانت‌اندهایی که دسترسی کارآمدی به تمام بازبینی‌های یک فایل منفرد دارند (برای مثال خواندن یک فایل ‎,v در RCS/CVS) می‌توانند انتخاب کنند که تمام بازبینی‌های آن فایل را به عنوان دنباله‌ای از دستورات متوالی \fBblob\fR ارائه دهند\&. این امر به fast\-import اجازه می‌دهد تا بازبینی‌های مختلف فایل را نسبت به یکدیگر دلتاسازی کند، و در فایل بسته نهایی در فضا صرفه‌جویی شود\&. می‌توان از نشان‌ها برای شناسایی بازبینی‌های منفرد فایل در طول دنباله‌ای از دستورات \fBcommit\fR در مراحل بعدی استفاده کرد\&.
.sp
فایل(های) بسته ایجادشده توسط fast\-import الگوهای دسترسی دیسک مناسبی را ترویج نمی‌کنند\&. این به دلیل آن است که fast\-import داده‌ها را به همان ترتیبی که در ورودی استاندارد دریافت می‌کند می‌نویسد، در حالی که گیت معمولاً داده‌ها را در فایل‌های بسته طوری سازمان‌دهی می‌کند که جدیدترین داده‌ها (نوک کنونی) پیش از داده‌های تاریخی قرار گیرند\&. گیت همچنین کامیت‌ها را با یکدیگر دسته‌بندی می‌کند، که پیمایش بازبینی‌ها را از طریق محلی‌سازی بهتر حافظه نهان سرعت می‌بخشد\&.
.sp
به همین دلیل اکیداً به کاربران توصیه می‌شود که پس از اتمام fast\-import، مخزن را با دستور \fBgit\fR \fBrepack\fR \fB\-a\fR \fB\-d\fR مجدداً بسته‌بندی کنند، تا به گیت اجازه داده شود فایل‌های بسته را برای دسترسی سریع‌تر به داده‌ها دوباره سازمان‌دهی کند\&. اگر دلتاهای blob غیربهینه باشند (به بالا مراجعه کنید)، اضافه کردن گزینه \fB\-f\fR برای وادار کردن به محاسبه مجدد همه دلتاها می‌تواند اندازه نهایی فایل بسته را به میزان قابل توجهی کاهش دهد (۳۰ تا ۵۰ درصد کوچک‌تر شدن کاملاً معمول است)\&.
.sp
به جای اجرای \fBgit\fR \fBrepack\fR، می‌توانید \fBgit\fR \fBgc\fR \fB\-\-aggressive\fR را نیز اجرا کنید که چیزهای دیگر را نیز پس از واردسازی بهینه‌سازی می‌کند (برای نمونه، بسته‌بندی ارجاعات سرگردان / pack loose refs)\&. همان‌طور که در بخش «AGGRESSIVE» در \fBgit-gc\fR(1) ذکر شده است، گزینه \fB\-\-aggressive\fR دلتاهای جدیدی را با گزینه \fB\-f\fR در \fBgit-repack\fR(1) خواهد یافت\&. به دلایلی که در بالا شرح داده شد، استفاده از \fB\-\-aggressive\fR پس از یک fast\-import یکی از معدود مواردی است که سودمند بودن آن شناخته شده است\&.
.SH "مصرف حافظه (MEMORY UTILIZATION)"
.sp
عوامل متعددی وجود دارند که بر میزان حافظه مورد نیاز fast\-import برای انجام یک واردسازی تأثیر می‌گذارند\&. همانند بخش‌های حیاتی هسته گیت، fast\-import از تخصیص‌دهنده‌های حافظه اختصاصی خود برای سرشکن کردن هرگونه سربار مرتبط با malloc استفاده می‌کند\&. در عمل، fast\-import به دلیل استفاده از تخصیص بلوک‌های بزرگ، تمایل دارد هرگونه سربار malloc را به صفر تقلیل دهد\&.
.SS "به ازای هر شیء (per object)"
.sp
برنامه fast\-import یک ساختار درون‌حافظه‌ای را برای هر شیء نوشته‌شده در این اجرا نگهداری می‌کند\&. در یک سیستم ۳۲ بیتی این ساختار ۳۲ بایت و در یک سیستم ۶۴ بیتی (به دلیل اندازه بزرگ‌تر اشاره‌گرها) این ساختار ۴۰ بایت است\&. اشیاء موجود در جدول تا زمان پایان یافتن fast\-import آزاد نمی‌شوند\&. وارد کردن ۲ میلیون شیء در یک سیستم ۳۲ بیتی تقریباً به ۶۴ مبی‌بایت (MiB) حافظه نیاز دارد\&.
.sp
جدول اشیاء در واقع یک جدول درهم‌سازی (hashtable) با کلید نام شیء (همان SHA\-1 یکتا) است\&. این پیکربندی ذخیره‌سازی به fast\-import اجازه می‌دهد تا از یک شیء موجود یا پیش‌تر نوشته‌شده مجدداً استفاده کند و از نوشتن موارد تکراری در فایل بسته خروجی خودداری نماید\&. حباب‌های تکراری در یک واردسازی به‌طور شگفت‌آوری رایج هستند که معمولاً به دلیل ادغام شاخه‌ها در مبدأ رخ می‌دهد\&.
.SS "به ازای هر نشان (per mark)"
.sp
نشان‌ها در یک آرایه تنک (sparse array) ذخیره می‌شوند و به ازای هر نشان از ۱ اشاره‌گر (۴ بایت یا ۸ بایت، بسته به اندازه اشاره‌گر) استفاده می‌کنند\&. اگرچه این آرایه تنک است، اما همچنان به فرانت‌اندها اکیداً توصیه می‌شود از نشان‌های بین ۱ و n استفاده کنند، که در آن n تعداد کل نشان‌های مورد نیاز برای این واردسازی است\&.
.SS "به ازای هر شاخه (per branch)"
.sp
شاخه‌ها به دو دسته فعال و غیرفعال طبقه‌بندی می‌شوند\&. مصرف حافظه این دو دسته به‌طور چشمگیری متفاوت است\&.
.sp
شاخه‌های غیرفعال در ساختاری ذخیره می‌شوند که به ازای هر شاخه از ۹۶ یا ۱۲۰ بایت (به ترتیب در سیستم‌های ۳۲ بیتی یا ۶۴ بیتی)، به علاوه طول نام شاخه (معمولاً زیر ۲۰۰ بایت) استفاده می‌کند\&. برنامه fast\-import به‌راحتی تا ۱۰٬۰۰۰ شاخه غیرفعال را در کمتر از ۲ مبی‌بایت حافظه مدیریت خواهد کرد\&.
.sp
شاخه‌های فعال همان سربار شاخه‌های غیرفعال را دارند، اما همچنین شامل رونوشت‌هایی از هر درختی هستند که اخیراً در آن شاخه اصلاح شده است\&. اگر زیردرخت \fBinclude\fR از زمان فعال شدن شاخه اصلاح نشده باشد، محتویات آن در حافظه بارگذاری نخواهد شد، اما اگر زیردرخت \fBsrc\fR با یک کامیت از زمان فعال شدن شاخه اصلاح شده باشد، آنگاه محتویات آن در حافظه بارگذاری خواهد شد\&.
.sp
از آنجا که شاخه‌های فعال فراداده‌های مربوط به فایل‌های موجود در آن شاخه را ذخیره می‌کنند، اندازه ذخیره‌سازی آن‌ها در حافظه می‌تواند تا میزان قابل توجهی رشد کند (به پایین مراجعه کنید)\&.
.sp
برنامه fast\-import به‌طور خودکار شاخه‌های فعال را بر اساس یک الگوریتم ساده «کمترین استفاده اخیر» (LRU) به وضعیت غیرفعال منتقل می‌کند\&. زنجیره LRU در هر دستور \fBcommit\fR به‌روزرسانی می‌شود\&. حداکثر تعداد شاخه‌های فعال را می‌توان در خط فرمان با \-\-active\-branches= افزایش یا کاهش داد\&.
.SS "به ازای هر درخت فعال (per active tree)"
.sp
درخت‌ها (یا همان دایرکتوری‌ها) علاوه بر حافظه مورد نیاز برای ورودی‌هایشان (بخش \(lqبه ازای هر فایل فعال\(rq در زیر را ببینید)، تنها از ۱۲ بایت حافظه استفاده می‌کنند\&. هزینه یک درخت عملاً صفر است، چرا که سربار آن روی تک‌تک ورودی‌های فایل سرشکن می‌شود\&.
.SS "به ازای هر ورودی فایل فعال (per active file entry)"
.sp
فایل‌ها (و اشاره‌گرها به زیردرخت‌ها) در درخت‌های فعال، به ازای هر ورودی به ۵۲ یا ۶۴ بایت (در پلتفرم‌های ۳۲/۶۴ بیتی) نیاز دارند\&. برای صرفه‌جویی در فضا، نام فایل‌ها و درخت‌ها در یک جدول مشترک رشته‌ها تجمیع (pool) می‌شوند، که باعث می‌شود نام فایل \(lqMakefile\(rq صرف‌نظر از اینکه چند بار در پروژه تکرار شود، تنها از ۱۶ بایت (پس از احتساب سربار سرآیند رشته) استفاده کند\&.
.sp
الگوریتم LRU شاخه‌های فعال، هنگامی که با مخزن مشترک رشته‌های نام فایل و بارگذاری تنبل (lazy loading) زیردرخت‌ها همراه شود، به fast\-import اجازه می‌دهد تا پروژه‌هایی با بیش از ۲٬۰۰۰ شاخه و بیش از ۴۵٬۱۱۴ فایل را با ردپای حافظه بسیار محدود (کمتر از ۲\&.۷ مبی‌بایت به ازای هر شاخه فعال) به‌طور کارآمد وارد کند\&.
.SH "سیگنال‌ها (SIGNALS)"
.sp
ارسال \fBSIGUSR1\fR به فرایند \fIgit fast\-import\fR فایل بسته فعلی را زودهنگام به پایان می‌رساند و یک دستور \fBcheckpoint\fR را شبیه‌سازی می‌کند\&. کاربر کم‌حوصله می‌تواند از این امکان برای بررسی اجمالی اشیاء و ارجاعات در یک واردسازیِ در حال انجام استفاده کند، که البته به بهای مقداری زمان اجرای بیشتر و فشرده‌سازی ضعیف‌تر تمام می‌شود\&.
.SH "پیکربندی (CONFIGURATION)"
.sp
تمام موارد زیر این خط در این بخش، به‌صورت گزینش‌شده از مستندات \fBgit-config\fR(1) گنجانده شده‌اند\&. محتوا همان چیزی است که در آنجا یافت می‌شود:
.PP
fastimport\&.unpackLimit
.RS 4
اگر تعداد اشیاء واردشده توسط
\fBgit-fast-import\fR(1)
کمتر از این حد باشد، اشیاء به صورت فایل‌های شیء مجزا (loose) باز خواهند شد\&. با این حال، اگر تعداد اشیاء واردشده برابر یا بیشتر از این حد باشد، بسته به صورت یک بسته (pack) ذخیره خواهد شد\&. ذخیره بسته حاصل از یک fast\-import می‌تواند عملیات واردسازی را، به‌ویژه در سیستم‌های فایل کُند، سریع‌تر به پایان برساند\&. اگر تنظیم نشده باشد، مقدار
\fBtransfer\&.unpackLimit\fR
به جای آن استفاده می‌شود\&.
.RE
.SH "همچنین ببینید (SEE ALSO)"
.sp
\fBgit-fast-export\fR(1)
.SH "گیت (GIT)"
.sp
بخشی از مجموعه \fBgit\fR(1)