GIT-FORMAT-PATCH(1)               Git Manual               GIT-FORMAT-PATCH(1)

نام (NAME)
       git-format-patch - آماده‌سازی وصله‌ها برای ارسال با ایمیل

خلاصه دستور (SYNOPSIS)
       git format-patch [-k] [(-o|--output-directory) <dir> | --stdout]
                          [--no-thread | --thread[=<style>]]
                          [(--attach|--inline)[=<boundary>] | --no-attach]
                          [-s | --signoff]
                          [--signature=<signature> | --no-signature]
                          [--signature-file=<file>]
                          [-n | --numbered | -N | --no-numbered]
                          [--start-number <n>] [--numbered-files]
                          [--in-reply-to=<message-id>] [--suffix=.<sfx>]
                          [--ignore-if-in-upstream] [--always]
                          [--cover-from-description=<mode>]
                          [--rfc[=<rfc>]] [--subject-prefix=<subject-prefix>]
                          [(--reroll-count|-v) <n>]
                          [--to=<email>] [--cc=<email>]
                          [--[no-]cover-letter] [--quiet]
                          [--commit-list-format=<format-spec>]
                          [--[no-]encode-email-headers]
                          [--no-notes | --notes[=<ref>]]
                          [--interdiff=<previous>]
                          [--range-diff=<previous> [--creation-factor=<percent>]]
                          [--filename-max-length=<n>]
                          [--progress]
                          [<common-diff-options>]
                          [ <since> | <revision-range> ]


توضیحات (DESCRIPTION)
       هر کامیت غیرادغام را به همراه «وصله» (patch) آن در قالب یک «پیام» در
       ازای هر کامیت آماده می‌کند که قالبی شبیه به صندوق پستی یونیکس (UNIX
       mailbox) دارد. خروجی این دستور برای ارسال با ایمیل یا استفاده با git am
       بسیار مناسب است.

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

       •   یک هدر متادیتای مختصر که با From <commit> به همراه یک مهر زمانی
           ثابت Mon Sep 17 00:00:00 2001 آغاز می‌شود تا به برنامه‌هایی مانند
           "file(1)" کمک کند که تشخیص دهند فایل خروجی این دستور است، و
           فیلدهایی که هویت نویسنده، تاریخ نویسنده و عنوان تغییر (برگرفته از
           اولین پاراگراف پیام لاگ کامیت) را ثبت می‌کنند.

       •   پاراگراف دوم و پاراگراف‌های بعدی پیام لاگ کامیت.

       •   «وصله» که همان خروجی "diff -p --stat" (نگاه کنید به git-diff(1))
           میان کامیت و والد آن است.

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

       دو روش برای تعیین اینکه دستور روی کدام کامیت‌ها کار کند وجود دارد.

        1. یک کامیت منفرد، <since>، مشخص می‌کند کامیت‌هایی که به نوک شاخه فعلی
           ختم می‌شوند و در تاریخچه‌ای که به <since> ختم می‌شود حضور ندارند، در
           خروجی قرار گیرند.

        2. عبارت عمومی <revision-range> (بخش «مشخص کردن بازنگری‌ها (SPECIFYING
           REVISIONS)» را در gitrevisions(7) ببینید) به معنای کامیت‌های موجود
           در محدوده مشخص‌شده است.

       در صورت وجود یک <commit> منفرد، قاعده اول اولویت دارد. برای اعمال قاعده
       دوم، یعنی قالب‌بندی همه‌چیز از ابتدای تاریخچه تا <commit>، از گزینه
       --root استفاده کنید: git format-patch --root <commit>. اگر می‌خواهید فقط
       خود <commit> را قالب‌بندی کنید، می‌توانید این کار را با git format-patch
       -1 <commit> انجام دهید.

       به طور پیش‌فرض، هر فایل خروجی از ۱ به صورت متوالی شماره‌گذاری می‌شود و از
       خط اول پیام کامیت (که برای ایمنی نام مسیر پردازش شده) به عنوان نام فایل
       استفاده می‌کند. با گزینه --numbered-files، نام فایل‌های خروجی تنها عدد
       خواهند بود، بدون اینکه خط اول پیام کامیت به آن اضافه شود. نام فایل‌های
       خروجی در خروجی استاندارد چاپ می‌شود، مگر اینکه گزینه --stdout مشخص شده
       باشد.

       اگر -o مشخص شده باشد، فایل‌های خروجی در <dir> ایجاد می‌شوند. در غیر این
       صورت در دایرکتوری کاری فعلی ایجاد خواهند شد. مسیر پیش‌فرض را می‌توان با
       گزینه پیکربندی format.outputDirectory تنظیم کرد. گزینه -o بر
       format.outputDirectory اولویت دارد. برای ذخیره وصله‌ها در دایرکتوری کاری
       فعلی حتی زمانی که format.outputDirectory به جای دیگری اشاره دارد، از -o
       . استفاده کنید. تمام بخش‌های دایرکتوری ساخته خواهند شد.

       به طور پیش‌فرض، موضوع (subject) یک وصله تکی عبارت است از "[PATCH] " که
       پس از آن خطوط پیام کامیت تا اولین خط خالی قرار می‌گیرند (بخش بحث در git-
       commit(1) را ببینید).

       هنگامی که چندین وصله در خروجی تولید می‌شوند، پیشوند موضوع در عوض "[PATCH
       n/m] " خواهد بود. برای اجبار به افزودن 1/1 برای یک تک‌وصله، از -n
       استفاده کنید. برای حذف شماره‌های وصله از موضوع، از -N استفاده نمایید.

       در صورت دادن --thread، دستور git-format-patch هدرهای In-Reply-To و
       References را تولید می‌کند تا ایمیل‌های وصله دوم و بعدی به صورت پاسخی به
       اولین ایمیل نمایش داده شوند؛ این کار همچنین یک هدر Message-ID برای
       ارجاع ایجاد می‌کند.

گزینه‌ها (OPTIONS)
       -p, --no-stat
           وصله‌های ساده بدون هیچ diffstat تولید می‌کند.

       -U<n>, --unified=<n>
           تفاوت‌ها را با <n> خط از زمینه (context) تولید می‌کند. تعداد خطوط
           زمینه به طور پیش‌فرض diff.context یا اگر این متغیر پیکربندی تنظیم
           نشده باشد، ۳ است. (-U بدون <n> به دلیل یک اتفاق تاریخی به عنوان
           معادل -p پذیرفته می‌شود).

       --output=<file>
           خروجی را به جای خروجی استاندارد (stdout) در یک فایل مشخص می‌نویسد.

       --output-indicator-new=<char>, --output-indicator-old=<char>,
       --output-indicator-context=<char>
           نویسه مورد استفاده برای نشان دادن خطوط جدید، قدیمی یا زمینه را در
           وصله تولیدشده مشخص می‌کند. به طور معمول این نویسه‌ها به ترتیب +، - و
           ' ' هستند.

       --indent-heuristic
           اکتشاف (heuristic) جابه‌جایی مرزهای تکه diff برای خواناتر شدن وصله‌ها
           را فعال می‌کند. این حالت پیش‌فرض است.

       --no-indent-heuristic
           اکتشاف تورفتگی را غیرفعال می‌کند.

       --minimal
           زمان بیشتری صرف می‌کند تا مطمئن شود کوچک‌ترین diff ممکن تولید می‌شود.

       --patience
           یک diff با استفاده از الگوریتم «patience diff» تولید می‌کند.

       --histogram
           یک diff با استفاده از الگوریتم «histogram diff» تولید می‌کند.

       --anchored=<text>
           یک diff با استفاده از الگوریتم «anchored diff» تولید می‌کند.

           این گزینه می‌تواند بیش از یک بار مشخص شود.

           اگر خطی هم در مبدأ و هم در مقصد وجود داشته باشد، فقط یک بار تکرار
           شده باشد و با <text> شروع شود، این الگوریتم تلاش می‌کند تا از ظاهر
           شدن آن به عنوان حذف یا اضافه در خروجی جلوگیری کند. این گزینه به
           صورت درونی از الگوریتم "patience diff" استفاده می‌کند.

       --diff-algorithm=(patience|minimal|histogram|myers)
           یک الگوریتم diff انتخاب می‌کند. گونه‌ها به شرح زیرند:

           default, myers
               الگوریتم پایه‌ای و حریصانه diff. در حال حاضر، این حالت پیش‌فرض
               است.

           minimal
               زمان بیشتری صرف می‌کند تا مطمئن شود کوچک‌ترین diff ممکن تولید
               می‌شود.

           patience
               هنگام تولید وصله‌ها از الگوریتم "patience diff" استفاده می‌کند.

           histogram
               این الگوریتم، الگوریتم patience را گسترش می‌دهد تا «از عناصر
               مشترک با تکرار کم پشتیبانی کند».

           برای نمونه، اگر متغیر diff.algorithm را روی مقداری غیرپیش‌فرض تنظیم
           کرده‌اید و می‌خواهید از مقدار پیش‌فرض استفاده کنید، باید از گزینه
           --diff-algorithm=default استفاده کنید.

       --stat[=<width>[,<name-width>[,<count>]]]
           یک diffstat تولید می‌کند. به طور پیش‌فرض، تا جای ممکن فضا برای بخش
           نام فایل استفاده می‌شود و بقیه برای بخش نمودار اختصاص می‌یابد. حداکثر
           عرض به طور پیش‌فرض عرض ترمینال است یا در صورت عدم اتصال به ترمینال
           ۸۰ ستون خواهد بود و می‌توان آن را با <width> بازنویسی کرد. عرض بخش
           نام فایل را می‌توان با دادن عرض دیگری <name-width> پس از کاما یا با
           تنظیم diff.statNameWidth=<name-width> محدود کرد. عرض بخش نمودار را
           می‌توان با استفاده از --stat-graph-width=<graph-width> یا با تنظیم
           diff.statGraphWidth=<graph-width> محدود نمود. استفاده از --stat یا
           --stat-graph-width بر تمام دستوراتی که نمودار آمار تولید می‌کنند
           تأثیر می‌گذارد، در حالی که تنظیم diff.statNameWidth یا
           diff.statGraphWidth بر git format-patch تأثیر نمی‌گذارد. با دادن
           پارامتر سوم <count>، می‌توانید خروجی را به اولین <count> خط محدود
           کنید که در صورت وجود خطوط بیشتر، با ... دنبال خواهد شد.

           این پارامترها را می‌توان به طور جداگانه با --stat-width=<width>،
           --stat-name-width=<name-width> و --stat-count=<count> نیز تنظیم
           کرد.

       --compact-summary
           خلاصه‌ای فشرده از اطلاعات هدر گسترش‌یافته مانند ایجاد یا حذف فایل‌ها
           ("new" یا "gone"، و به صورت اختیاری +l در صورتی که پیوند نمادین
           باشد) و تغییرات حالت (+x یا -x به ترتیب برای افزودن یا حذف بیت
           اجرایی) را در diffstat ارائه می‌دهد. اطلاعات بین بخش نام فایل و بخش
           نمودار قرار می‌گیرد. مستلزم --stat است.

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

       --shortstat
           فقط آخرین خط قالب --stat شامل تعداد کل فایل‌های تغییریافته و نیز
           تعداد خطوط اضافه‌شده و حذف‌شده را در خروجی می‌دهد.

       -X [<param>,...], --dirstat[=<param>,...]
           توزیع مقدار نسبی تغییرات را برای هر زیردایرکتوری خروجی می‌دهد. رفتار
           --dirstat را می‌توان با ارسال فهرستی از پارامترهای جداشده با کاما به
           آن سفارشی کرد. مقادیر پیش‌فرض توسط متغیر پیکربندی diff.dirstat کنترل
           می‌شوند (نگاه کنید به git-config(1)).  پارامترهای زیر در دسترس
           هستند:

           changes
               اعداد dirstat را با شمارش خطوطی که از مبدأ حذف شده یا به مقصد
               اضافه شده‌اند محاسبه می‌کند. این پارامتر مقدار جابه‌جایی خالص کد
               در یک فایل را نادیده می‌گیرد؛ به عبارت دیگر، مرتب‌سازی مجدد خطوط
               در یک فایل به اندازه تغییرات دیگر شمرده نمی‌شود. این رفتار
               پیش‌فرض در صورت عدم ارائه پارامتر است.

           lines
               اعداد dirstat را با انجام تحلیل معمول diff مبتنی بر خط و جمع
               زدن تعداد خطوط حذف‌شده/اضافه‌شده محاسبه می‌کند. (برای فایل‌های
               باینری، به جای آن بلوک‌های ۶۴ بایتی را شمارش می‌کند، زیرا فایل‌های
               باینری مفهوم طبیعی خط ندارند). این رفتار --dirstat نسبت به
               رفتار changes سنگین‌تر است، اما خطوط مرتب‌شده مجدد درون یک فایل
               را به اندازه سایر تغییرات به حساب می‌آورد. خروجی حاصل با آنچه از
               سایر گزینه‌های --*stat دریافت می‌کنید سازگار است.

           files
               اعداد dirstat را با شمارش تعداد فایل‌های تغییریافته محاسبه
               می‌کند. هر فایل تغییریافته در تحلیل dirstat وزن یکسانی دارد. این
               از نظر محاسباتی کم‌هزینه‌ترین رفتار --dirstat است، زیرا اصلاً
               نیازی به بررسی محتوای فایل ندارد.

           cumulative
               تغییرات موجود در یک دایرکتوری فرزند را برای دایرکتوری والد نیز
               محاسبه می‌کند. توجه داشته باشید که هنگام استفاده از cumulative،
               مجموع درصدهای گزارش‌شده ممکن است از 100% فراتر رود. رفتار پیش‌فرض
               (غیرتجمعی) را می‌توان با پارامتر noncumulative مشخص کرد.

           <limit>
               یک پارامتر عدد صحیح درصد آستانه را مشخص می‌کند (به طور پیش‌فرض
               3%). دایرکتوری‌هایی که کمتر از این درصد در تغییرات سهم دارند در
               خروجی نمایش داده نمی‌شوند.

           مثال: دستور زیر فایل‌های تغییریافته را شمارش می‌کند، در حالی که
           دایرکتوری‌های با کمتر از 10% کل فایل‌های تغییریافته را نادیده می‌گیرد
           و شمارش دایرکتوری فرزند را در دایرکتوری‌های والد تجمیع می‌نماید:
           --dirstat=files,10,cumulative.

       --cumulative
           مترادف برای --dirstat=cumulative.

       --dirstat-by-file[=<param>,...]
           مترادف برای --dirstat=files,<param>,....

       --summary
           خلاصه‌ای فشرده از اطلاعات هدر گسترش‌یافته مانند ایجادها، تغییر نام‌ها
           و تغییرات حالت را ارائه می‌دهد.

       --no-renames
           تشخیص تغییر نام را خاموش می‌کند، حتی اگر فایل پیکربندی پیش‌فرض را
           برای انجام آن تعیین کرده باشد.

       --rename-empty, --no-rename-empty
           مشخص می‌کند که آیا از blobهای خالی به عنوان منبع تغییر نام استفاده
           شود یا خیر.

       --full-index
           به جای چند نویسه اول، نام‌های کامل اشیاء blob قبل و بعد از تصویر را
           روی خط "index" هنگام تولید خروجی قالب وصله نشان می‌دهد.

       --binary
           علاوه بر --full-index، یک diff باینری خروجی می‌دهد که می‌توان آن را
           با git-apply اعمال کرد.

       --abbrev[=<n>]
           به جای نمایش نام کامل هگزادسیمال ۴۰ بایتی شیء در خروجی قالب
           diff-raw و خطوط هدر diff-tree، کوتاه‌ترین پیشوندی را نشان می‌دهد که
           حداقل <n> رقم هگزادسیمال طول داشته و به صورت یکتا به شیء ارجاع دهد.
           در قالب خروجی diff-patch، گزینه --full-index اولویت بالاتری دارد،
           یعنی اگر --full-index مشخص شده باشد، نام‌های کامل blob بدون در نظر
           گرفتن --abbrev نشان داده می‌شوند. تعداد ارقام غیرپیش‌فرض را می‌توان با
           --abbrev=<n> مشخص کرد.

       -B[<n>][/<m>], --break-rewrites[=[<n>][/<m>]]
           تغییرات بازنویسی کامل را به جفت‌های حذف و ایجاد تقسیم می‌کند. این کار
           دو هدف را برآورده می‌سازد:

           تغییری را که به منزله بازنویسی کلی یک فایل است، نه به عنوان
           مجموعه‌ای از حذف و درج‌های آمیخته با چند خط که به طور متنی تطابق
           دارند، بلکه به صورت یک حذف کلی تمام موارد قدیمی و سپس یک درج کلی
           تمام موارد جدید نشان می‌دهد؛ و عدد <m> این جنبه از گزینه -B را کنترل
           می‌کند (به طور پیش‌فرض 60%).  -B/70% مشخص می‌کند که کمتر از 30% از
           نسخه اصلی باید در نتیجه باقی بماند تا گیت آن را بازنویسی کامل تلقی
           کند (یعنی در غیر این صورت وصله حاصل مجموعه‌ای از حذف و درج‌های آمیخته
           با خطوط زمینه خواهد بود).

           هنگامی که همراه با -M استفاده می‌شود، یک فایل کاملاً بازنویسی‌شده نیز
           به عنوان منبع یک تغییر نام در نظر گرفته می‌شود (معمولاً -M فقط فایلی
           را که ناپدید شده به عنوان منبع تغییر نام در نظر می‌گیرد)، و عدد <n>
           این جنبه از گزینه -B را کنترل می‌کند (به طور پیش‌فرض 50%).  -B20%
           مشخص می‌کند تغییری با افزودن و حذف معادل 20% یا بیشتر از اندازه
           فایل، واجد شرایط است که به عنوان منبع احتمالی تغییر نام به فایلی
           دیگر در نظر گرفته شود.

       -M[<n>], --find-renames[=<n>]
           تغییر نام‌ها را تشخیص می‌دهد. اگر <n> مشخص شده باشد، آستانه‌ای برای
           شاخص شباهت است (یعنی مقدار افزودن/حذف در مقایسه با اندازه فایل).
           برای مثال، -M90% به این معنی است که اگر بیش از 90% فایل تغییر نکرده
           باشد، گیت باید یک جفت حذف/اضافه را تغییر نام در نظر بگیرد. بدون
           علامت %، عدد به صورت یک کسر خوانده می‌شود که یک ممیز اعشاری قبل از
           آن قرار دارد؛ یعنی -M5 برابر با 0.5 شده و بنابراین مشابه -M50% است.
           به طور مشابه، -M05 معادل -M5% است. برای محدود کردن تشخیص به تغییر
           نام‌های دقیق، از -M100% استفاده کنید. شاخص شباهت پیش‌فرض 50% است.

       -C[<n>], --find-copies[=<n>]
           کپی‌ها و همچنین تغییر نام‌ها را تشخیص می‌دهد. همچنین
           --find-copies-harder را ببینید. اگر <n> مشخص شود، معنای یکسانی با
           -M<n> دارد.

       --find-copies-harder
           به دلایل کارایی، به طور پیش‌فرض، گزینه -C کپی‌ها را تنها در صورتی
           پیدا می‌کند که فایل اصلیِ کپی در همان مجموعه تغییرات (changeset)
           اصلاح شده باشد. این فلگ باعث می‌شود دستور، فایل‌های اصلاح‌نشده را نیز
           به عنوان نامزدهای منبع کپی بررسی کند. این یک عملیات بسیار سنگین
           برای پروژه‌های بزرگ است، بنابراین با احتیاط از آن استفاده کنید. دادن
           بیش از یک گزینه -C تأثیر یکسانی دارد.

       -D, --irreversible-delete
           پیش‌تصویر (preimage) را برای حذف‌ها حذف می‌کند، یعنی فقط هدر را چاپ
           می‌کند اما تفاوت بین پیش‌تصویر و /dev/null را چاپ نمی‌نماید. وصله حاصل
           قرار نیست با patch یا git apply اعمال شود؛ این فقط برای افرادی است
           که صرفاً می‌خواهند روی بازبینی متن پس از تغییر تمرکز کنند. علاوه بر
           این، خروجی به وضوح فاقد اطلاعات کافی برای اعمال معکوس چنین وصله‌ای
           حتی به صورت دستی است، از این رو نام گزینه چنین انتخاب شده است.

           هنگامی که همراه با -B استفاده می‌شود، پیش‌تصویر را در بخش حذف یک جفت
           حذف/ایجاد نیز حذف می‌کند.

       -l<num>
           گزینه‌های -M و -C شامل مراحلی مقدماتی هستند که می‌توانند
           زیرمجموعه‌هایی از تغییر نام‌ها/کپی‌ها را به صورت کم‌هزینه تشخیص دهند، و
           سپس یک بخش بازگشتی کامل که تمام مقصدهای جفت‌نشده باقی‌مانده را با
           تمام منابع مرتبط مقایسه می‌کند. (برای تغییر نام‌ها، فقط منابع جفت‌نشده
           باقی‌مانده مرتبط هستند؛ برای کپی‌ها، تمام منابع اصلی مرتبط هستند).
           برای N منبع و مقصد، این بررسی کامل از مرتبه O(N^2) است. این گزینه
           در صورتی که تعداد فایل‌های مبدأ/مقصد درگیر از تعداد مشخص‌شده فراتر
           رود، از اجرای بخش کامل تشخیص تغییر نام/کپی جلوگیری می‌کند. پیش‌فرض
           diff.renameLimit است. توجه داشته باشید که مقدار 0 به معنای نامحدود
           در نظر گرفته می‌شود.

       -O<orderfile>
           ترتیب نمایش فایل‌ها در خروجی را کنترل می‌کند. این گزینه متغیر
           پیکربندی diff.orderFile را بازنویسی می‌کند (نگاه کنید به git-
           config(1)).  برای لغو diff.orderFile، از -O/dev/null استفاده کنید.

           ترتیب خروجی با ترتیب الگوهای glob در <orderfile> تعیین می‌شود. همه
           فایل‌هایی با نام مسیرهایی که با الگوی اول مطابقت دارند ابتدا خروجی
           داده می‌شوند، همه فایل‌هایی با نام مسیرهایی که با الگوی دوم (اما نه
           اول) مطابقت دارند بعدی هستند، و به همین ترتیب. همه فایل‌هایی با نام
           مسیرهایی که با هیچ الگویی مطابقت ندارند در انتها خروجی داده می‌شوند،
           گویی یک الگوی ضمنی تطابق با همه‌چیز در انتهای فایل وجود داشته است.
           اگر چند نام مسیر رتبه یکسانی داشته باشند (با همان الگو مطابقت داشته
           باشند اما با هیچ الگوی قبلی مطابقت نداشته باشند)، ترتیب خروجی آن‌ها
           نسبت به یکدیگر همان ترتیب عادی است.

           <orderfile> به صورت زیر تجزیه می‌شود:

           •   خطوط خالی نادیده گرفته می‌شوند، بنابراین می‌توان از آن‌ها به عنوان
               جداکننده برای خوانایی استفاده کرد.

           •   خطوطی که با علامت هش ("#") شروع می‌شوند نادیده گرفته می‌شوند،
               بنابراین می‌توان از آن‌ها برای توضیحات استفاده کرد. اگر الگو با
               هش شروع می‌شود، یک بک‌اسلش ("\") به ابتدای الگو اضافه کنید.

           •   هر خط دیگر شامل یک الگوی منفرد است.

           الگوها همان نحو و معنای الگوهای مورد استفاده برای fnmatch(3) بدون
           فلگ FNM_PATHNAME را دارند، با این تفاوت که اگر حذف هر تعداد از
           مؤلفه‌های پایانی نام مسیر با الگو مطابقت داشته باشد، نام مسیر نیز با
           الگو مطابقت دارد. برای مثال، الگوی "foo*bar" با "fooasdfbar" و
           "foo/bar/baz/asdf" مطابقت دارد، اما با "foobarx" مطابقت ندارد.

       --skip-to=<file>, --rotate-to=<file>
           فایل‌های قبل از <file> مشخص‌شده را از خروجی دور می‌اندازد (یعنی پرش به
           <file>)، یا آن‌ها را به انتهای خروجی منتقل می‌کند (یعنی چرخش به
           <file>). این گزینه‌ها عمدتاً برای استفاده دستور git difftool ابداع
           شده‌اند و در غیر این صورت ممکن است چندان مفید نباشند.

       --relative[=<path>], --no-relative
           هنگامی که از یک زیردایرکتوری پروژه اجرا می‌شود، می‌توان با این گزینه
           به آن گفت که تغییرات خارج از دایرکتوری را مستثنی کرده و نام مسیرها
           را به صورت نسبی نسبت به آن نشان دهد. هنگامی که در یک زیردایرکتوری
           نیستید (مثلاً در یک مخزن bare)، می‌توانید با دادن یک <path> به عنوان
           آرگومان، نام زیردایرکتوری را که می‌خواهید خروجی نسبت به آن باشد مشخص
           کنید.  --no-relative را می‌توان برای ابطال هر دو گزینه پیکربندی
           diff.relative و --relative قبلی استفاده کرد.

       -a, --text
           همه فایل‌ها را به عنوان متن در نظر می‌گیرد.

       --ignore-cr-at-eol
           هنگام مقایسه، carriage-return را در انتهای خط نادیده می‌گیرد.

       --ignore-space-at-eol
           تغییرات در فاصله‌های خالی در انتهای خط (EOL) را نادیده می‌گیرد.

       -b, --ignore-space-change
           تغییرات در مقدار فاصله خالی را نادیده می‌گیرد. این گزینه فاصله خالی
           در انتهای خط را نادیده گرفته و همه دنباله‌های دیگر از یک یا چند
           نویسه فاصله خالی را معادل یکدیگر در نظر می‌گیرد.

       -w, --ignore-all-space
           هنگام مقایسه خطوط، فاصله خالی را نادیده می‌گیرد. این گزینه تفاوت‌ها
           را حتی اگر یک خط دارای فاصله خالی باشد و دیگری فاقد آن، نادیده
           می‌گیرد.

       --ignore-blank-lines
           تغییراتی را که خطوط آن‌ها کاملاً خالی هستند نادیده می‌گیرد.

       -I<regex>, --ignore-matching-lines=<regex>
           تغییراتی را که همه خطوط آن‌ها با <regex> مطابقت دارند نادیده می‌گیرد.
           این گزینه ممکن است بیش از یک بار مشخص شود.

       --inter-hunk-context=<number>
           زمینه بین تکه‌های diff را تا حداکثر <number> خط مشخص‌شده نشان می‌دهد،
           و بدین ترتیب تکه‌هایی را که به یکدیگر نزدیک هستند ادغام می‌کند. مقدار
           پیش‌فرض diff.interHunkContext است یا اگر این گزینه پیکربندی تنظیم
           نشده باشد، برابر با 0 خواهد بود.

       -W, --function-context
           کل تابع را به عنوان خطوط زمینه برای هر تغییر نشان می‌دهد. نام توابع
           به همان روشی تعیین می‌شود که git diff هدرهای تکه وصله را به دست
           می‌آورد (بخش «تعریف یک هدر تکه سفارشی» را در gitattributes(5)
           ببینید).

       --ext-diff
           اجازه می‌دهد یک ابزار کمکی diff خارجی اجرا شود. اگر یک درایور diff
           خارجی را با gitattributes(5) تنظیم کرده‌اید، باید از این گزینه همراه
           با git-log(1) و موارد مشابه استفاده کنید.

       --no-ext-diff
           درایورهای diff خارجی را غیرمجاز می‌کند.

       --textconv, --no-textconv
           اجازه اجرای (یا عدم اجرای) فیلترهای تبدیل متن خارجی را هنگام مقایسه
           فایل‌های باینری می‌دهد. برای جزئیات به gitattributes(5) مراجعه کنید.
           از آنجا که فیلترهای textconv معمولاً یک تبدیل یک‌طرفه هستند، diff
           حاصل برای خواندن توسط انسان مناسب است اما اعمال آن ممکن نیست. به
           همین دلیل، فیلترهای textconv به طور پیش‌فرض تنها برای git-diff(1) و
           git-log(1) فعال هستند، نه برای git-format-patch(1) یا دستورات diff
           لایه زیرین (plumbing).

       --ignore-submodules[=(none|untracked|dirty|all)]
           تغییرات در زیرماژول‌ها را در تولید diff نادیده می‌گیرد.  all حالت
           پیش‌فرض است. استفاده از none زمانی زیرماژول را اصلاح‌شده در نظر
           می‌گیرد که یا حاوی فایل‌های ردیابی‌نشده یا اصلاح‌شده باشد، یا HEAD آن
           با کامیت ثبت‌شده در پروژه والد تفاوت داشته باشد، و می‌تواند برای
           بازنویسی تنظیمات گزینه ignore در git-config(1) یا gitmodules(5)
           استفاده شود. هنگامی که untracked استفاده می‌شود، زیرماژول‌ها زمانی که
           تنها حاوی محتوای ردیابی‌نشده هستند آلوده (dirty) تلقی نمی‌شوند (اما
           همچنان برای محتوای اصلاح‌شده اسکن می‌شوند). استفاده از dirty تمام
           تغییرات در درخت کاری زیرماژول‌ها را نادیده می‌گیرد و تنها تغییرات در
           کامیت‌های ذخیره‌شده در پروژه والد نشان داده می‌شوند (این رفتار تا نسخه
           1.7.0 بود). استفاده از all تمام تغییرات در زیرماژول‌ها را پنهان
           می‌کند.

       --src-prefix=<prefix>
           پیشوند مبدأ داده‌شده <prefix> را به جای "a/" نشان می‌دهد.

       --dst-prefix=<prefix>
           پیشوند مقصد داده‌شده <prefix> را به جای "b/" نشان می‌دهد.

       --no-prefix
           هیچ پیشوند مبدأ یا مقصدی را نشان نمی‌دهد.

       --default-prefix
           از پیشوندهای پیش‌فرض مبدأ و مقصد ("a/" و "b/") استفاده می‌کند. این
           گزینه متغیرهای پیکربندی مانند format.noprefix، diff.srcPrefix،
           diff.dstPrefix و diff.mnemonicPrefix را بازنویسی می‌کند (نگاه کنید
           به git-config(1)).

       --line-prefix=<prefix>
           یک <prefix> اضافی را به ابتدای هر خط خروجی اضافه می‌کند.

       --ita-invisible-in-index
           به طور پیش‌فرض، مدخل‌های اضافه‌شده با git add -N به صورت یک فایل خالی
           موجود در git diff و یک فایل جدید در git diff --cached ظاهر می‌شوند.
           این گزینه باعث می‌شود مدخل به عنوان یک فایل جدید در git diff و
           ناموجود در git diff --cached ظاهر شود. این گزینه را می‌توان با
           --ita-visible-in-index برگرداند. هر دو گزینه آزمایشی هستند و ممکن
           است در آینده حذف شوند.

       --max-depth=<depth>
           به ازای هر pathspec داده‌شده در خط فرمان، حداکثر تا <depth> سطح
           دایرکتوری پایین می‌رود. مقدار -1 به معنای نامحدود است. نمی‌تواند با
           نویسه‌های عام (wildcard) در pathspec ترکیب شود. با فرض درختی حاوی
           foo/bar/baz، فهرست زیر تطابق‌های ایجادشده توسط هر مجموعه گزینه را
           نشان می‌دهد:

           •   --max-depth=0 -- foo: foo

           •   --max-depth=1 -- foo: foo/bar

           •   --max-depth=1 -- foo/bar: foo/bar/baz

           •   --max-depth=1 -- foo foo/bar: foo/bar/baz

           •   --max-depth=2 -- foo: foo/bar/baz

           اگر هیچ pathspec مشخص نشود، عمق طوری سنجیده می‌شود که گویی تمام
           مدخل‌های سطح بالا مشخص شده‌اند. توجه داشته باشید که این با اندازه‌گیری
           از ریشه متفاوت است، به این ترتیب که --max-depth=0 همچنان foo را
           برمی‌گرداند. این به شما امکان می‌دهد در حالی که زیرمجموعه‌ای از
           مدخل‌های سطح بالا را درخواست می‌کنید، عمق را نیز محدود کنید.

           توجه داشته باشید که این گزینه فقط برای diffهای میان اشیاء درخت
           پشتیبانی می‌شود، نه در برابر ایندکس یا درخت کاری.

       برای توضیحات مفصل‌تر درباره این گزینه‌های مشترک، gitdiffcore(7) را نیز
       ببینید.

       -<n>
           وصله‌ها را از بالاترین <n> کامیت آماده می‌کند.

       -o <dir>, --output-directory <dir>
           از <dir> برای ذخیره فایل‌های حاصل، به جای دایرکتوری کاری فعلی
           استفاده می‌کند.

       -n, --numbered
           نام‌گذاری خروجی را در قالب [PATCH n/m] قرار می‌دهد، حتی اگر یک تک‌وصله
           باشد.

       -N, --no-numbered
           نام‌گذاری خروجی را در قالب [PATCH] قرار می‌دهد.

       --start-number <n>
           شماره‌گذاری وصله‌ها را از <n> به جای 1 آغاز می‌کند.

       --numbered-files
           نام فایل‌های خروجی یک دنباله عددی ساده خواهد بود بدون اینکه خط اول
           پیش‌فرض کامیت به آن اضافه شود.

       -k, --keep-subject
           عبارت [PATCH] را از خط اول پیام گزارش کامیت حذف یا به آن اضافه
           نمی‌کند.

       -s, --signoff
           یک تریلر Signed-off-by با استفاده از هویت کامیت‌کننده خودتان به پیام
           کامیت اضافه می‌کند. برای اطلاعات بیشتر گزینه signoff را در git-
           commit(1) ببینید.

       --stdout
           تمام کامیت‌ها را در قالب mbox در خروجی استاندارد چاپ می‌کند، به جای
           اینکه برای هر کدام یک فایل ایجاد کند.

       --attach[=<boundary>]
           پیوست چندبخشی multipart/mixed ایجاد می‌کند که بخش اول آن پیام کامیت
           و وصله در بخش دوم است، با Content-Disposition: attachment.

       --no-attach
           ایجاد پیوست را غیرفعال کرده و تنظیمات پیکربندی را بازنویسی می‌کند.

       --inline[=<boundary>]
           پیوست چندبخشی multipart/mixed ایجاد می‌کند که بخش اول آن پیام کامیت
           و وصله در بخش دوم است، با Content-Disposition: inline.

       --thread[=<style>], --no-thread
           افزودن هدرهای In-Reply-To و References را کنترل می‌کند تا ایمیل‌های
           دوم و بعدی به صورت پاسخی به ایمیل اول ظاهر شوند. همچنین تولید هدر
           Message-ID برای ارجاع را کنترل می‌کند.

           آرگومان اختیاری <style> می‌تواند shallow یا deep باشد.  shallow
           (سطحی) هر ایمیل را به پاسخی به سر سری (head) تبدیل می‌کند، که سر سری
           از میان نامه پوششی (cover letter)، --in-reply-to و اولین ایمیل
           وصله، به همین ترتیب انتخاب می‌شود.  deep (عمیق) هر ایمیل را به پاسخی
           به ایمیل قبلی تبدیل می‌کند.

           پیش‌فرض --no-thread است، مگر اینکه پیکربندی format.thread تنظیم شده
           باشد.  --thread بدون آرگومان معادل --thread=shallow است.

           توجه داشته باشید که پیش‌فرض git send-email این است که خودش ایمیل‌ها
           را رشته‌بندی کند. اگر می‌خواهید git format-patch رشته‌بندی را انجام
           دهد، باید اطمینان حاصل کنید که رشته‌بندی برای git send-email غیرفعال
           شده است.

       --in-reply-to=<message-id>
           کاری می‌کند که ایمیل اول (یا تمام ایمیل‌ها با --no-thread) به صورت
           پاسخی به <message-id> داده‌شده ظاهر شوند، که این کار از شکستن رشته‌ها
           هنگام ارائه یک سری وصله جدید جلوگیری می‌کند.

       --ignore-if-in-upstream
           وصله‌ای را که با کامیتی در <until>..<since> مطابقت دارد شامل نمی‌کند.
           این گزینه تمام وصله‌های قابل دسترس از <since> اما غیرقابل دسترس از
           <until> را بررسی کرده و آن‌ها را با وصله‌های در حال تولید مقایسه
           می‌کند، و هر وصله‌ای که مطابقت داشته باشد نادیده گرفته می‌شود.

       --always
           وصله‌ها را برای کامیت‌هایی که هیچ تغییری ایجاد نمی‌کنند (و به طور
           پیش‌فرض حذف می‌شوند) شامل می‌کند.

       --cover-from-description=<mode>
           کنترل می‌کند کدام بخش‌های نامه پوششی (cover letter) با استفاده از
           توضیحات شاخه به طور خودکار پر شوند.

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

           اگر <mode> برابر با subject باشد، اولین پاراگراف توضیحات شاخه موضوع
           نامه پوششی را پر می‌کند. بقیه توضیحات بدنه نامه پوششی را پر خواهد
           کرد.

           اگر <mode> برابر با auto باشد، چنانچه اولین پاراگراف توضیحات شاخه
           بزرگ‌تر از ۱۰۰ بایت باشد، حالت message خواهد بود، و در غیر این صورت
           subject استفاده می‌شود.

           اگر <mode> برابر با none باشد، هم موضوع و هم بدنه نامه پوششی با متن
           جایگزین پر خواهند شد.

       --description-file=<file>
           از محتوای <file> به جای توضیحات شاخه برای تولید نامه پوششی استفاده
           می‌کند.

       --subject-prefix=<subject-prefix>
           به جای پیشوند استاندارد [PATCH] در خط موضوع، از [<subject-prefix>]
           استفاده می‌کند. این گزینه می‌تواند برای نام‌گذاری یک سری وصله به کار
           رود و با گزینه --numbered ترکیب شود.

           متغیر پیکربندی format.subjectPrefix نیز ممکن است برای پیکربندی یک
           پیشوند موضوع جهت اعمال روی تمام وصله‌های یک مخزن مشخص استفاده شود.
           این معمولاً در لیست‌های ایمیلی که وصله‌های چندین مخزن را دریافت می‌کنند
           مفید است و می‌تواند برای ابهام‌زدایی از وصله‌ها به کار رود (مثلاً با
           مقداری مانند "PATCH my-project").

       --filename-max-length=<n>
           به جای مقدار استاندارد ۶۴ بایت، نام فایل‌های خروجی تولیدشده را در
           حدود <n> بایت برش می‌دهد (مقدار خیلی کوتاه بدون هشدار به یک طول
           معقول افزایش می‌یابد). پیش‌فرض مقدار متغیر پیکربندی
           format.filenameMaxLength است، یا ۶۴ در صورتی که پیکربندی نشده باشد.

       --rfc[=<rfc>]
           رشته <rfc> (به طور پیش‌فرض "RFC") را به ابتدای پیشوند موضوع اضافه
           می‌کند. از آنجا که پیشوند موضوع به طور پیش‌فرض "PATCH" است، شما به
           صورت پیش‌فرض "RFC PATCH" را دریافت خواهید کرد.

           عبارت RFC به معنای «درخواست برای نظرات» (Request For Comments) است؛
           زمانی از این گزینه استفاده کنید که یک وصله آزمایشی را برای بحث و
           تبادل نظر ارسال می‌کنید و نه برای اعمال شدن. گزینه "--rfc=WIP" نیز
           ممکن است روش مفیدی برای نشان دادن این باشد که یک وصله هنوز کامل
           نشده است ("WIP" مخفف "Work In Progress" یا کار در حال انجام است).

           اگر رسم جامعه دریافت‌کننده برای یک رشته اضافی خاص این باشد که بعد از
           پیشوند موضوع قرار گیرد، می‌توان رشته <rfc> را با یک خط تیره ("-")
           شروع کرد تا نشان دهد بقیه رشته <rfc> باید به انتهای پیشوند موضوع
           اضافه شود، برای مثال، --rfc='-(WIP)' منجر به "PATCH (WIP)" می‌شود.

       -v <n>, --reroll-count=<n>
           سری وصله‌ها را به عنوان تکرار (نسخه) <n>ام از موضوع علامت‌گذاری
           می‌کند. به ابتدای نام فایل‌های خروجی v<n> اضافه می‌شود و به انتهای
           پیشوند موضوع ("PATCH" به طور پیش‌فرض، اما قابل تنظیم با گزینه
           --subject-prefix) عبارت ` v<n>` الحاق می‌گردد؛ به عنوان مثال
           --reroll-count=4 ممکن است فایل v4-0001-add-makefile.patch را تولید
           کند که دارای "Subject: [PATCH v4 1/20] Add makefile" در درون خود
           است.  <n> لازم نیست حتماً یک عدد صحیح باشد (مثلاً
           "--reroll-count=4.4" یا "--reroll-count=4rev2" مجاز هستند)، اما
           نکته منفی استفاده از چنین reroll-count این است که
           range-diff/interdiff با نسخه قبلی دقیقاً مشخص نمی‌کند که تکرار جدید
           در مقایسه با کدام نسخه است.

       --to=<email>
           یک هدر To: به هدرهای ایمیل اضافه می‌کند. این علاوه بر هرگونه هدر
           پیکربندی‌شده است و می‌تواند چندین بار استفاده شود. حالت نفی --no-to
           تمام هدرهای To: اضافه‌شده تا کنون را (از پیکربندی یا خط فرمان) دور
           می‌اندازد.

       --cc=<email>
           یک هدر Cc: به هدرهای ایمیل اضافه می‌کند. این علاوه بر هرگونه هدر
           پیکربندی‌شده است و می‌تواند چندین بار استفاده شود. حالت نفی --no-cc
           تمام هدرهای Cc: اضافه‌شده تا کنون را (از پیکربندی یا خط فرمان) دور
           می‌اندازد.

       --from, --from=<ident>
           از ident در هدر From: هر ایمیل استفاده می‌کند. در مورد ایمیل یک
           کامیت، اگر شناسه نویسنده (author ident) کامیت به صورت متنی با ident
           ارائه‌شده یکسان نباشد، یک هدر From: در بدنه پیام با نویسنده اصلی
           قرار می‌دهد. اگر هیچ ident مشخص نشود، یا اگر این گزینه اصلاً داده
           نشود، از شناسه کامیت‌کننده فعلی استفاده می‌کند.

           توجه داشته باشید که این گزینه فقط در صورتی مفید است که واقعاً در حال
           ارسال ایمیل‌ها باشید و بخواهید خود را به عنوان فرستنده معرفی کنید،
           اما نویسنده اصلی را حفظ نمایید (و git am به درستی هدر درون بدنه را
           برمی‌دارد). همچنین توجه داشته باشید که git send-email قبلاً این تبدیل
           را برای شما انجام می‌دهد، و اگر خروجی را به git send-email می‌دهید
           نباید از این گزینه استفاده شود.

       --force-in-body-from, --no-force-in-body-from
           با مشخص شدن فرستنده ایمیل از طریق گزینه --from، به طور پیش‌فرض اگر
           فرستنده با نویسنده متفاوت باشد، یک "From:" درون بدنه برای شناسایی
           نویسنده واقعی کامیت در بالای پیام گزارش کامیت اضافه می‌شود. با این
           گزینه، "From:" درون بدنه حتی زمانی که فرستنده و نویسنده نام و آدرس
           یکسانی دارند اضافه می‌شود، که ممکن است در صورتی که نرم‌افزار لیست
           ایمیل هویت فرستنده را مخدوش کند کمک‌کننده باشد. پیش‌فرض مقدار متغیر
           پیکربندی format.forceInBodyFrom است.

       --add-header=<header>
           یک هدر دلخواه به هدرهای ایمیل اضافه می‌کند. این علاوه بر هرگونه هدر
           پیکربندی‌شده است و می‌تواند چندین بار استفاده شود. برای مثال،
           --add-header="Organization: git-foo".  حالت نفی --no-add-header
           تمام هدرهای (To:، Cc: و سفارشی) اضافه‌شده تا کنون را از پیکربندی یا
           خط فرمان دور می‌اندازد.

       --cover-letter, --no-cover-letter
           علاوه بر وصله‌ها، یک فایل نامه پوششی حاوی توضیحات شاخه، فهرست
           کامیت‌ها و diffstat کلی تولید می‌کند. شما می‌توانید پیش از ارسال،
           توضیحی را در فایل پر کنید.

       --commit-list-format=<format-spec>
           قالبی را مشخص می‌کند که فهرست کامیت‌های سری وصله در آن تولید می‌شود.
           مقادیر پذیرفته‌شده برای format-spec عبارتند از shortlog، modern یا
           یک رشته قالب با پیشوند log:؛ برای مثال log: %s (%an).  modern مشابه
           log:%w(72)[%(count)/%(total)] %s است. اگر رشته قالب دارای یک % در
           درون خود باشد (با این انتظار که بخشی از %<placeholder> باشد)،
           پیشوند log: می‌تواند حذف شود. پیش‌فرض متغیر پیکربندی
           format.commitListFormat در صورت تنظیم، یا shortlog است. دادن این
           گزینه از خط فرمان مستلزم استفاده از --cover-letter است مگر اینکه
           --no-cover-letter داده شود.

       --encode-email-headers, --no-encode-email-headers
           هدرهای ایمیلی را که دارای نویسه‌های غیر ASCII هستند با "Q-encoding"
           (توصیف‌شده در RFC 2047) کدگذاری می‌کند، به جای اینکه هدرها را عیناً در
           خروجی بیاورد. پیش‌فرض مقدار متغیر پیکربندی format.encodeEmailHeaders
           است.

       --interdiff=<previous>
           به عنوان کمکی به بازبین، یک interdiff را در نامه پوششی، یا به عنوان
           توضیحی در وصله منفرد یک سری تک‌وصله‌ای درج می‌کند که تفاوت‌های بین نسخه
           قبلی سری وصله و سری در حال قالب‌بندی فعلی را نشان می‌دهد.  previous
           یک بازنگری منفرد است که نام نوک سری قبلی را مشخص می‌کند که دارای یک
           پایه مشترک با سری در حال قالب‌بندی است (برای مثال git format-patch
           --cover-letter --interdiff=feature/v1 -3 feature/v2).

       --range-diff=<previous>
           به عنوان کمکی به بازبین، یک range-diff (نگاه کنید به git-range-
           diff(1)) را در نامه پوششی، یا به عنوان توضیحی در وصله منفرد یک سری
           تک‌وصله‌ای درج می‌کند که تفاوت‌های بین نسخه قبلی سری وصله و سری در حال
           قالب‌بندی فعلی را نشان می‌دهد.  previous می‌تواند یک بازنگری منفرد
           باشد که نام نوک سری قبلی را در صورتی که پایه مشترکی با سری در حال
           قالب‌بندی داشته باشد مشخص کند (برای مثال git format-patch
           --cover-letter --range-diff=feature/v1 -3 feature/v2)، یا یک محدوده
           بازنگری در صورتی که دو نسخه از سری مجزا از هم باشند (برای مثال git
           format-patch --cover-letter --range-diff=feature/v1~3..feature/v1
           -3 feature/v2).

           توجه داشته باشید که گزینه‌های diff ارسال‌شده به دستور بر چگونگی تولید
           محصول اصلی format-patch تأثیر می‌گذارند، و به مکانیزم زیرین
           range-diff که برای تولید محتوای نامه پوششی استفاده می‌شود ارسال
           نمی‌شوند (این ممکن است در آینده تغییر کند).

       --creation-factor=<percent>
           همراه با --range-diff استفاده می‌شود؛ اکتشافی را که کامیت‌ها را بین
           سری قبلی و فعلی وصله‌ها مطابقت می‌دهد، با تنظیم ضریب تطبیق هزینه
           ایجاد/حذف تنظیم دقیق می‌کند. برای جزئیات git-range-diff(1) را
           ببینید.

           مقدار پیش‌فرض 999 است (دستور git-range-diff(1) از 60 استفاده می‌کند)،
           زیرا کاربرد در اینجا نمایش مقایسه با تکرار قدیمی‌تر از همان موضوع
           است و ابزار باید تطابق بیشتری بین دو مجموعه وصله پیدا کند.

       --notes[=<ref>], --no-notes
           یادداشت‌ها (نگاه کنید به git-notes(1)) مربوط به کامیت را پس از خط سه
           خط تیره الحاق می‌کند.

           مورد استفاده مورد انتظار از این گزینه، نوشتن توضیحات پشتیبان برای
           کامیت است که به خود پیام لاگ کامیت تعلق ندارد، و گنجاندن آن در
           ارسال وصله است. در حالی که فرد می‌تواند به سادگی این توضیحات را پس
           از اجرای format-patch اما پیش از ارسال بنویسد، نگه داشتن آن‌ها به
           عنوان یادداشت‌های گیت اجازه می‌دهد تا میان نسخه‌های مختلف سری وصله حفظ
           شوند (اما برای استفاده از این گردش کار، بحث گزینه‌های پیکربندی
           notes.rewrite را در git-notes(1) ببینید).

           پیش‌فرض --no-notes است، مگر اینکه پیکربندی format.notes تنظیم شده
           باشد.

       --signature=<signature>, --no-signature
           یک امضا به هر پیام تولیدشده اضافه می‌کند. طبق RFC 3676 امضا با خطی
           حاوی '-- ' از بدنه جدا می‌شود. اگر گزینه امضا حذف شود، امضا به طور
           پیش‌فرض شماره نسخه گیت خواهد بود.

       --signature-file=<file>
           دقیقاً مانند --signature کار می‌کند به جز اینکه امضا از یک فایل
           خوانده می‌شود.

       --suffix=.<sfx>
           به جای استفاده از .patch به عنوان پسوند برای نام فایل‌های تولیدشده،
           از پسوند مشخص‌شده استفاده می‌کند. یک جایگزین رایج --suffix=.txt است.
           خالی گذاشتن این مقدار پسوند .patch را حذف می‌کند.

           توجه داشته باشید که نویسه آغازین لازم نیست نقطه باشد؛ برای مثال،
           می‌توانید از --suffix=-patch برای به دست آوردن
           0001-description-of-my-change-patch استفاده کنید.

       -q, --quiet
           نام فایل‌های تولیدشده را در خروجی استاندارد چاپ نمی‌کند.

       --no-binary
           محتوای تغییرات در فایل‌های باینری را در خروجی قرار نمی‌دهد، بلکه در
           عوض اعلانی مبنی بر تغییر آن فایل‌ها نمایش می‌دهد. وصله‌های تولیدشده با
           این گزینه نمی‌توانند به درستی اعمال شوند، اما همچنان برای بازبینی کد
           مفید هستند.

       --zero-commit
           یک هش کاملاً صفر را در هدر From هر وصله به جای هش کامیت خروجی می‌دهد.

       --no-base, --base[=<commit>]
           اطلاعات درخت پایه را برای شناسایی وضعیتی که سری وصله روی آن اعمال
           می‌شود ثبت می‌کند. برای جزئیات، بخش اطلاعات درخت پایه را در زیر
           ببینید. اگر <commit> برابر با "auto" باشد، یک کامیت پایه به طور
           خودکار انتخاب می‌شود. گزینه --no-base پیکربندی format.useAutoBase را
           بازنویسی می‌کند.

       --root
           آرگومان revision را به عنوان یک <revision-range> در نظر می‌گیرد، حتی
           اگر فقط یک کامیت منفرد باشد (که معمولاً به عنوان یک <since> در نظر
           گرفته می‌شود). توجه داشته باشید که کامیت‌های ریشه موجود در محدوده
           مشخص‌شده همیشه به عنوان وصله‌های ایجاد قالب‌بندی می‌شوند، مستقل از این
           فلگ.

       --progress
           گزارش‌های پیشرفت را همزمان با تولید وصله‌ها روی stderr نشان می‌دهد.

پیکربندی (CONFIGURATION)
       شما می‌توانید خطوط هدر اضافی ایمیل برای اضافه شدن به هر پیام، مقادیر
       پیش‌فرض برای پیشوند موضوع و پسوند فایل، شماره‌گذاری وصله‌ها هنگام خروجی
       دادن بیش از یک وصله، افزودن هدرهای "To:" یا "Cc:"، پیکربندی پیوست‌ها،
       تغییر دایرکتوری خروجی وصله، و امضا کردن (sign off) وصله‌ها را با
       متغیرهای پیکربندی مشخص کنید.

           [format]
                   headers = "Organization: git-foo\n"
                   subjectPrefix = CHANGE
                   suffix = .txt
                   numbered = auto
                   to = <email>
                   cc = <email>
                   attach [ = mime-boundary-string ]
                   signOff = true
                   outputDirectory = <directory>
                   coverLetter = auto
                   commitListFormat = shortlog
                   coverFromDescription = auto


بحث (DISCUSSION)
       وصله تولیدشده توسط git format-patch در قالب صندوق پستی یونیکس (UNIX
       mailbox) است، با یک مهر زمانی ثابت و جادویی ("magic") برای نشان دادن
       اینکه فایل خروجی format-patch است و نه یک صندوق پستی واقعی، به این
       صورت:

           From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001
           From: Tony Luck <tony.luck@intel.com>
           Date: Tue, 13 Jul 2010 11:42:54 -0700
           Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?=
            =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?=
           MIME-Version: 1.0
           Content-Type: text/plain; charset=UTF-8
           Content-Transfer-Encoding: 8bit

           arch/arm config files were slimmed down using a python script
           (See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)

           Do the same for ia64 so we can have sleek & trim looking
           ...


       به طور معمول این فایل در پوشه پیش‌نویس‌های (drafts) نرم‌افزار MUA قرار
       می‌گیرد، ویرایش می‌شود تا توضیحات به‌موقع که نباید بعد از سه خط تیره در
       گزارش تغییرات قرار گیرند به آن اضافه شوند، و سپس به عنوان پیامی ارسال
       می‌شود که بدنه آن، در مثال ما، با "arch/arm config files were..." شروع
       می‌شود. در سمت دریافت‌کننده، خوانندگان می‌توانند وصله‌های جالب را در یک
       صندوق پستی یونیکس ذخیره کرده و آن‌ها را با git-am(1) اعمال کنند.

       هنگامی که یک وصله بخشی از یک بحث ادامه‌دار است، وصله تولیدشده توسط git
       format-patch می‌تواند طوری تنظیم شود که از ویژگی git am --scissors
       بهره‌مند شود. پس از پاسخ شما به بحث، خطی می‌آید که صرفاً شامل "-- >8 --"
       (قیچی و خط برش) است، و پس از آن وصله با حذف فیلدهای هدر غیرضروری قرار
       می‌گیرد:

           ...
           > So we should do such-and-such.

           Makes sense to me.  How about this patch?

           -- >8 --
           Subject: [IA64] Put ia64 config files on the Uwe Kleine-König diet

           arch/arm config files were slimmed down using a python script
           ...


       هنگام ارسال وصله به این روش، اغلب شما در حال ارسال وصله خودتان هستید،
       بنابراین علاوه بر نشانگر "From $SHA1 $magic_timestamp"، باید خطوط From:
       و Date: را از فایل وصله حذف کنید. عنوان وصله احتمالاً با موضوع بحثی که
       وصله در پاسخ به آن است تفاوت دارد، بنابراین به احتمال زیاد می‌خواهید خط
       Subject: را مانند مثال بالا حفظ کنید.

   بررسی خرابی وصله
       بسیاری از نرم‌افزارهای ایمیل در صورت عدم تنظیم مناسب، فاصله‌های خالی را
       خراب می‌کنند. در اینجا دو نوع خرابی رایج آورده شده است:

       •   خطوط زمینه خالی که هیچ فاصله خالی ندارند.

       •   خطوط زمینه غیرخالی که یک فاصله خالی اضافی در ابتدا دارند.

       یک روش برای آزمایش اینکه آیا MUA شما به درستی تنظیم شده است یا خیر:

       •   وصله را برای خودتان ارسال کنید، دقیقاً همان‌طور که معمولاً ارسال
           می‌کردید، به جز اینکه خطوط To: و Cc: شامل آدرس لیست ایمیل و
           نگه‌دارنده نباشند.

       •   آن وصله را در فایلی با فرمت صندوق پستی یونیکس ذخیره کنید؛ مثلاً آن
           را a.patch بنامید.

       •   آن را اعمال کنید:

               $ git fetch <project> master:test-apply
               $ git switch test-apply
               $ git restore --source=HEAD --staged --worktree :/
               $ git am a.patch

       اگر به درستی اعمال نشد، دلایل مختلفی می‌تواند داشته باشد.

       •   خود وصله به درستی اعمال نمی‌شود. این بد است اما ارتباط چندانی با MUA
           شما ندارد. در این حالت ممکن است بخواهید پیش از تولید مجدد، وصله را
           با git-rebase(1) ریبیس کنید.

       •   نرم‌افزار MUA وصله شما را خراب کرده است؛ "am" شکایت خواهد کرد که
           وصله اعمال نمی‌شود. به زیردایرکتوری .git/rebase-apply/ نگاه کنید و
           بررسی کنید که فایل patch شامل چه چیزی است و الگوهای رایج خرابی
           ذکرشده در بالا را بررسی کنید.

       •   در همان حین، فایل‌های info و final-commit را نیز بررسی کنید. اگر
           آنچه در final-commit قرار دارد دقیقاً همان چیزی نیست که می‌خواهید در
           پیام گزارش کامیت ببینید، بسیار محتمل است که دریافت‌کننده هنگام اعمال
           وصله مجبور شود پیام گزارش را به صورت دستی ویرایش کند. مواردی مانند
           "سلام، این اولین وصله من است.\n" در ایمیل وصله باید پس از خط سه خط
           تیره که نشان‌دهنده پایان پیام کامیت است قرار گیرند.

نکات ویژه کلاینت‌های ایمیل (MUA-SPECIFIC HINTS)
       در اینجا نکاتی درباره نحوه ارسال موفقیت‌آمیز وصله‌ها به صورت درون‌متنی
       (inline) با استفاده از برنامه‌های مختلف ایمیل آورده شده است.

   جیمیل (GMail)
       جیمیل هیچ راهی برای خاموش کردن شکستن خودکار خطوط (line wrapping) در
       رابط وب ندارد، بنابراین هر ایمیلی را که ارسال می‌کنید مخدوش خواهد کرد.
       با این حال می‌توانید از "git send-email" استفاده کرده و وصله‌های خود را
       از طریق سرور SMTP جیمیل ارسال کنید، یا از هر کلاینت ایمیل IMAP برای
       اتصال به سرور IMAP گوگل استفاده کرده و ایمیل‌ها را از طریق آن فوروارد
       نمایید.

       برای نکاتی درباره استفاده از git send-email جهت ارسال وصله‌هایتان از
       طریق سرور SMTP جیمیل، بخش مثال در git-send-email(1) را ببینید.

       برای نکاتی درباره ارسال با استفاده از رابط IMAP، بخش مثال در git-imap-
       send(1) را ببینید.

   تاندربرد (Thunderbird)
       به طور پیش‌فرض، تاندربرد هم خطوط ایمیل را می‌شکند و هم آن‌ها را به عنوان
       format=flowed علامت‌گذاری می‌کند، که هر دوی این‌ها ایمیل حاصل را برای گیت
       غیرقابل استفاده می‌کنند.

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

       رویکرد ۱ (افزونه)

           افزونه Toggle Line Wrap را که از نشانی
           https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap
           در دسترس است نصب کنید. این افزونه دکمه‌ای به نام "Line Wrap" به نوار
           ابزار ایجاد پیام اضافه می‌کند که می‌توانید آن را غیرفعال کنید. اکنون
           می‌توانید پیام را به همان روش معمول خود بسازید (برش + چسباندن، git
           format-patch | git imap-send و غیره)، اما باید شکستگی خطوط را به
           صورت دستی در هر متنی که تایپ می‌کنید درج نمایید.

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

           این افزونه به چند تغییر جزئی در پیکربندی پیشرفته (about:config)
           نیاز دارد که این موارد در صفحه دانلود فهرست شده‌اند.

       رویکرد ۲ (پیکربندی)

           سه مرحله:

            1. ایجاد پیام در سرور ایمیل خود را به عنوان متن ساده (plain text)
               پیکربندی کنید: Edit...Account Settings...Composition &
               Addressing، علامت "Compose Messages in HTML" را بردارید.

            2. پنجره عمومی ایجاد پیام را پیکربندی کنید تا خطوط را نشکند.

               در Thunderbird 2: مسیر Edit..Preferences..Composition، مقدار
               wrap plain text messages را روی 0 تنظیم کنید.

               در Thunderbird 3: مسیر Edit..Preferences..Advanced..Config
               Editor. عبارت "mail.wrap_long_lines" را جستجو کنید. آن را تغییر
               دهید تا مطمئن شوید روی false تنظیم شده است. همچنین
               "mailnews.wraplength" را جستجو کرده و مقدار آن را روی 0 قرار
               دهید.

            3. استفاده از format=flowed را غیرفعال کنید:
               Edit..Preferences..Advanced..Config Editor. عبارت
               "mailnews.send_plaintext_flowed" را جستجو کنید. آن را تغییر
               دهید تا مطمئن شوید روی false تنظیم شده است.

           پس از انجام این کار، باید بتوانید ایمیل را همان‌طور که معمولاً انجام
           می‌دادید ایجاد کنید (برش + چسباندن، git format-patch | git imap-send
           و غیره) و وصله‌ها مخدوش نخواهند شد.

       رویکرد ۳ (ویرایشگر خارجی)

           افزونه‌های زیر برای تاندربرد مورد نیاز هستند: AboutConfig از
           https://mjg.github.io/AboutConfig و External Editor از
           https://globs.org/articles.php?lng=en&pg=8

            1. وصله را به عنوان یک فایل متنی با استفاده از روش دلخواه خود
               آماده کنید.

            2. پیش از باز کردن پنجره ایجاد پیام، از مسیر Edit→Account Settings
               علامت گزینه "Compose messages in HTML format" را در پنل
               "Composition & Addressing" حسابی که برای ارسال وصله استفاده
               می‌شود بردارید.

            3. در پنجره اصلی تاندربرد، پیش از اینکه پنجره ایجاد پیام را برای
               وصله باز کنید، از مسیر Tools→about:config برای تنظیم مقادیر
               نشان‌داده‌شده زیر استفاده نمایید:

                           mailnews.send_plaintext_flowed  => false
                           mailnews.wraplength             => 0


            4. یک پنجره ایجاد پیام باز کنید و روی آیکون ویرایشگر خارجی کلیک
               نمایید.

            5. در پنجره ویرایشگر خارجی، فایل وصله را فراخوانی کرده و از
               ویرایشگر به طور معمول خارج شوید.

           نکته حاشیه‌ای: ممکن است بتوان مرحله ۲ را با about:config و تنظیمات
           زیر انجام داد، اما هنوز کسی آن را امتحان نکرده است.

                       mail.html_compose                       => false
                       mail.identity.default.compose_html      => false
                       mail.identity.id?.compose_html          => false


           اسکریپتی در contrib/thunderbird-patch-inline وجود دارد که می‌تواند
           به شما کمک کند تا وصله‌ها را به روشی آسان در تاندربرد بگنجانید. برای
           استفاده از آن، مراحل بالا را انجام دهید و سپس از این اسکریپت به
           عنوان ویرایشگر خارجی استفاده کنید.

   کی‌میل (KMail)
       این بخش به شما کمک می‌کند تا با استفاده از KMail وصله‌ها را به صورت
       درون‌متنی (inline) ارسال کنید.

        1. وصله را به صورت یک فایل متنی آماده کنید.

        2. روی New Mail کلیک کنید.

        3. به بخش "Options" در پنجره پیام‌ساز بروید و مطمئن شوید که "Word wrap"
           فعال نباشد.

        4. از Message → Insert file... استفاده کرده و وصله را درج نمایید.

        5. به پنجره ایجاد پیام بازگردید: هر متن دیگری را که می‌خواهید به پیام
           اضافه کنید، فیلدهای آدرس و موضوع را تکمیل کرده و ارسال (send) را
           بزنید.

اطلاعات درخت پایه (BASE TREE INFORMATION)
       بلوک اطلاعات درخت پایه توسط نگه‌دارنده‌ها یا آزمایش‌کنندگان شخص ثالث
       استفاده می‌شود تا وضعیت دقیقی را که سری وصله روی آن اعمال می‌شود بدانند.
       این بلوک شامل کامیت پایه است که یک کامیت شناخته‌شده و بخشی از بخش پایدار
       تاریخچه پروژه است که سایر افراد کار خود را بر پایه آن بنا می‌کنند، و صفر
       یا چند وصله پیش‌نیاز، که وصله‌های شناخته‌شده در حال پیشرفت هستند که هنوز
       بخشی از کامیت پایه نیستند و باید روی کامیت پایه به ترتیب توپولوژیکی
       اعمال شوند تا بتوان این وصله‌ها را اعمال کرد.

       کامیت پایه به صورت "base-commit: " و به دنبال آن نام شیء کامیت به صورت
       هگزادسیمال ۴۰ رقمی نشان داده می‌شود. یک وصله پیش‌نیاز به صورت
       "prerequisite-patch-id: " و به دنبال آن شناسه وصله ۴۰ رقمی نشان داده
       می‌شود، که می‌توان آن را با ارسال وصله به دستور git patch-id --stable به
       دست آورد.

       تصور کنید که روی کامیت عمومی P، وصله‌های شناخته‌شده X، Y و Z را از شخص
       دیگری اعمال کرده‌اید، و سپس سری سه وصله‌ای خود یعنی A، B و C را ساخته‌اید؛
       تاریخچه به این شکل خواهد بود:

           ---P---X---Y---Z---A---B---C

       با git format-patch --base=P -3 C (یا گونه‌های دیگر آن، مثلاً با
       --cover-letter یا با استفاده از Z..C به جای -3 C برای مشخص کردن
       محدوده)، بلوک اطلاعات درخت پایه در انتهای اولین پیامی که دستور خروجی
       می‌دهد (یا اولین وصله، یا نامه پوششی) به این صورت نشان داده می‌شود:

           base-commit: P
           prerequisite-patch-id: X
           prerequisite-patch-id: Y
           prerequisite-patch-id: Z


       برای توپولوژی غیرخطی، مانند

           ---P---X---A---M---C
               \         /
                Y---Z---B

       همچنین می‌توانید از git format-patch --base=P -3 C برای تولید وصله‌های A،
       B و C استفاده کنید، و شناسه‌های P، X، Y و Z به انتهای اولین پیام پیوست
       می‌شوند.

       اگر --base=auto در خط فرمان تنظیم شود، کامیت پایه به طور خودکار به
       عنوان پایه ادغامِ (merge base) کامیت نوک شاخه ردیابی از راه دور و محدوده
       بازنگری مشخص‌شده در خط فرمان محاسبه می‌شود. برای یک شاخه محلی، پیش از
       استفاده از این گزینه باید با git branch --set-upstream-to آن را طوری
       تنظیم کنید که یک شاخه از راه دور را ردیابی کند.

مثال‌ها (EXAMPLES)
       •   استخراج کامیت‌های بین بازنگری‌های R1 و R2، و اعمال آن‌ها بر روی شاخه
           فعلی با استفاده از git am برای گلچین کردن (cherry-pick) آن‌ها:

               $ git format-patch -k --stdout R1..R2 | git am -3 -k


       •   استخراج تمام کامیت‌هایی که در شاخه فعلی هستند اما در شاخه origin
           نیستند:

               $ git format-patch origin

           برای هر کامیت یک فایل جداگانه در دایرکتوری فعلی ایجاد می‌شود.

       •   استخراج تمام کامیت‌هایی که از ابتدای پروژه به origin ختم می‌شوند:

               $ git format-patch --root origin


       •   مشابه مورد قبلی:

               $ git format-patch -M -B origin

           علاوه بر این، تغییر نام‌ها و بازنویسی‌های کامل را به طور هوشمندانه
           تشخیص داده و مدیریت می‌کند تا یک وصله تغییر نام تولید نماید. یک وصله
           تغییر نام مقدار متن خروجی را کاهش می‌دهد و به طور کلی بازبینی آن را
           آسان‌تر می‌کند. توجه داشته باشید که برنامه‌های "patch" غیر از گیت،
           وصله‌های تغییر نام را متوجه نمی‌شوند، بنابراین فقط زمانی از آن
           استفاده کنید که می‌دانید دریافت‌کننده از گیت برای اعمال وصله شما
           استفاده می‌کند.

       •   استخراج سه کامیت بالایی از شاخه فعلی و قالب‌بندی آن‌ها به صورت
           وصله‌های قابل ارسال با ایمیل:

               $ git format-patch -3


هشدارها (CAVEATS)
       توجه داشته باشید که format-patch کامیت‌های ادغام را از خروجی حذف می‌کند،
       حتی اگر بخشی از محدوده درخواستی باشند. یک "وصله" ساده شامل اطلاعات کافی
       برای سمت دریافت‌کننده جهت بازتولید همان کامیت ادغام نیست.

   اعمال وصله (PATCH APPLICATION)
       خروجی حاصل از git-format-patch(1) هنگامی که با git-am(1) اعمال می‌شود
       می‌تواند به پیام کامیت متفاوتی منجر گردد. وصله‌ای که اعمال می‌شود نیز ممکن
       است با وصله‌ای که تولید شده بود تفاوت داشته باشد، یا اعمال وصله ممکن است
       کاملاً با شکست مواجه شود.

       هر خطی که به شکل:

       •   سه خط تیره و انتهای خط، یا

       •   خطی که با diff - شروع می‌شود، یا

       •   خطی که با `Index: ` شروع می‌شود

       باشد، به عنوان شروع یک وصله در نظر گرفته می‌شود و پیام گزارش کامیت قبل
       از اولین وقوع چنین خطی خاتمه می‌یابد.

       توجه داشته باشید که این به ویژه برای diffهای فاقد تورفتگی که در پیام
       کامیت رخ می‌دهند مشکل‌ساز است؛ diff موجود در پیام کامیت ممکن است همراه با
       بخش وصله اعمال شود، یا سازوکار اعمال وصله ممکن است دچار خطا شود زیرا
       هدف وصله اعمال نمی‌شود. این می‌تواند به عنوان مثال به دلیل یک diff در یک
       بلوک کد Markdown رخ دهد.

       راه حل این موضوع، ایجاد تورفتگی برای diff یا سایر متونی است که می‌توانند
       مشکل ایجاد کنند.

       این کاهش دقت ممکن است در صورت اعمال مستقیم وصله‌ها از صندوق پستی به
       سادگی قابل توجه باشد. با این حال، تغییرات منشأگرفته از گیت می‌توانند به
       صورت دسته‌ای اعمال شوند، که در این صورت توجه به آن بسیار دشوارتر خواهد
       بود. این می‌تواند برای مثال یک توزیع لینوکس باشد که از فایل‌های وصله برای
       اعمال تغییرات بر روی کامیت‌های مخازن بالادستی استفاده می‌کند. این نشان
       می‌دهد که این رفتار تنها بر جریان‌های کاری ایمیل تأثیر نمی‌گذارد.

       با توجه به این محدودیت‌ها، ممکن است فرد وسوسه شود به جای آن از یک ابزار
       عمومی مانند patch(1) استفاده کند. با این حال، patch(1) نه تنها به دنبال
       diffهای فاقد تورفتگی می‌گردد (مانند git-am(1))، بلکه تلاش می‌کند diffهای
       دارای تورفتگی را نیز اعمال کند.

همچنین ببینید (SEE ALSO)
       git-am(1), git-send-email(1)

گیت (GIT)
       بخشی از مجموعه git(1)

Git 2.55.0                        2026-06-29               GIT-FORMAT-PATCH(1)