GIT-SHOW(1) دستورات عمومی کاربر GIT-SHOW(1)

git-show - نمایش انواع مختلف اشیاء

git show [<options>] [<object>...]

یک یا چند شیء (blobها، درخت‌ها، برچسب‌ها و کامیت‌ها) را نمایش می‌دهد.

برای کامیت‌ها، پیام لاگ و تفاضل متنی (textual diff) را نمایش می‌دهد. همچنین کامیت ادغام (merge) را با قالب ویژه‌ای که توسط git diff-tree --cc تولید می‌شود ارائه می‌کند.

برای برچسب‌ها، پیام برچسب و اشیای ارجاع‌شده را نشان می‌دهد.

برای درخت‌ها، نام‌ها را نمایش می‌دهد (معادل git ls-tree با --name-only).

برای blobهای ساده، محتویات متنی ساده را نمایش می‌دهد.

برخی از گزینه‌هایی که دستور git log می‌فهمد را می‌توان برای کنترل نحوه نمایش تغییرات ارائه‌شده توسط کامیت استفاده کرد.

این صفحه راهنما تنها پرکاربردترین گزینه‌ها را شرح می‌دهد.

<object>...

نام اشیاء برای نمایش (به‌طور پیش‌فرض HEAD). برای فهرست کامل‌تری از روش‌های نگارش نام اشیاء، بخش "SPECIFYING REVISIONS" را در gitrevisions(7) ببینید.

--pretty[=<format>], --format=<format>

محتوای لاگ‌های کامیت را با قالبی زیبا در قالب داده‌شده نمایش می‌دهد، که در آن <format> می‌تواند یکی از موارد oneline, short, medium, full, fuller, reference, email, raw, format:<string> و tformat:<string> باشد. هنگامی که <format> هیچ‌یک از موارد بالا نباشد و حاوی %<placeholder> باشد، به‌گونه‌ای عمل می‌کند که گویی --pretty=tformat:<format> داده شده است.

برای جزئیات بیشتر درباره هر قالب، بخش «PRETTY FORMATS» را ببینید. هنگامی که بخش =<format> حذف شود، مقدار پیش‌فرض medium خواهد بود.


نکته
می‌توانید قالب پیش‌فرض نمایش را در پیکربندی مخزن مشخص کنید (به git-config(1) مراجعه کنید).

--abbrev-commit

به‌جای نمایش نام کامل هگزادسیمال ۴۰ بایتی شیء کامیت، پیشوندی را نشان می‌دهد که شیء را به‌طور منحصربه‌فرد نام‌گذاری کند. گزینه --abbrev=<n> (که در صورت نمایش خروجی diff، آن را نیز اصلاح می‌کند) می‌تواند برای تعیین حداقل طول پیشوند استفاده شود.

این گزینه باید خوانایی --pretty=oneline را برای افرادی که از ترمینال‌های ۸۰ ستونی استفاده می‌کنند به مراتب بهتر کند.

--no-abbrev-commit

نام کامل هگزادسیمال ۴۰ بایتی شیء کامیت را نمایش می‌دهد. این گزینه اثر --abbrev-commit را، چه صریح باشد و چه به‌طور ضمنی توسط گزینه‌های دیگر مانند --oneline ایجاد شده باشد، خنثی می‌کند. همچنین متغیر log.abbrevCommit را بازنویسی می‌نماید.

--oneline

این گزینه یک حالت کوتاه‌نویسی برای استفاده همزمان از --pretty=oneline و --abbrev-commit است.

--encoding=<encoding>

اشیای کامیت، کدگذاری نویسه‌های استفاده‌شده برای پیام لاگ را در هدر encoding خود ثبت می‌کنند؛ این گزینه می‌تواند به دستور بگوید پیام لاگ کامیت را با کدگذاری مورد نظر کاربر مجدداً کدگذاری کند. برای دستورات غیر زیرساختی (non-plumbing)، این مقدار به‌طور پیش‌فرض UTF-8 است. توجه داشته باشید اگر یک شیء ادعا کند با X کدگذاری شده است و ما با X خروجی بدهیم، شیء را عیناً خروجی می‌دهیم؛ این بدان معنی است که توالی‌های نامعتبر در کامیت اصلی ممکن است به خروجی کپی شوند. مشابهاً، اگر تابع iconv(3) در تبدیل کامیت شکست بخورد، شیء اصلی را بدون اعلام خطا عیناً خروجی خواهیم داد.

--expand-tabs=<n>, --expand-tabs, --no-expand-tabs

پیش از نمایش پیام لاگ در خروجی، تب‌ها را گسترش می‌دهد (هر تب را با تعداد کافی فاصله جایگزین می‌کند تا به ستون نمایش بعدی که مضربی از <n> است پر شود). --expand-tabs حالت کوتاه‌نویسی برای --expand-tabs=8, و --no-expand-tabs حالت کوتاه‌نویسی برای --expand-tabs=0 است که گسترش تب‌ها را غیرفعال می‌کند.

به‌طور پیش‌فرض، تب‌ها در قالب‌های زیبایی که پیام لاگ را ۴ فاصله تورفتگی می‌دهند (یعنی medium که پیش‌فرض است، full, و fuller) گسترش می‌یابند.

--notes[=<ref>]

هنگام نمایش پیام لاگ کامیت، یادداشت‌هایی را که کامیت را حاشیه‌نویسی می‌کنند (به git-notes(1) مراجعه کنید) نشان می‌دهد. این رفتار پیش‌فرض برای دستورات git log, git show و git whatchanged است، در صورتی که هیچ گزینه --pretty, --format, یا --oneline در خط فرمان داده نشده باشد.

به‌طور پیش‌فرض، یادداشت‌های نمایش‌داده‌شده از ارجاع‌های یادداشت فهرست‌شده در متغیرهای core.notesRef و notes.displayRef (یا بازنویسی‌های متغیرهای محیطی متناظر) برگرفته می‌شوند. برای جزئیات بیشتر به git-config(1) مراجعه کنید.

با یک آرگومان اختیاری <ref>, از آن ارجاع برای یافتن یادداشت‌ها جهت نمایش استفاده می‌کند. ارجاع می‌تواند نام کامل ارجاع را هنگامی که با refs/notes/ آغاز می‌شود مشخص کند؛ هنگامی که با notes/ آغاز شود، پیشوند refs/ و در غیر این صورت refs/notes/ برای تشکیل نام کامل ارجاع اضافه می‌گردد.

می‌توان چندین گزینه --notes را با هم ترکیب کرد تا مشخص شود چه یادداشت‌هایی نمایش داده می‌شوند. مثال‌ها: "--notes=foo" تنها یادداشت‌های refs/notes/foo را نشان می‌دهد؛ "--notes=foo --notes" هم یادداشت‌های "refs/notes/foo" و هم یادداشت‌های ارجاع(های) یادداشت پیش‌فرض را نشان می‌دهد.

--no-notes

یادداشت‌ها را نشان نمی‌دهد. این گزینه با بازنشانی فهرست ارجاع‌های یادداشت که یادداشت‌ها از آن‌ها نمایش داده می‌شوند، گزینه --notes فوق را خنثی می‌کند. گزینه‌ها به ترتیبی که در خط فرمان داده شده‌اند تجزیه می‌شوند، بنابراین برای نمونه "--notes --notes=foo --no-notes --notes=bar" تنها یادداشت‌های refs/notes/bar را نشان خواهد داد.

--show-notes-by-default

یادداشت‌های پیش‌فرض را نشان می‌دهد مگر اینکه گزینه‌هایی برای نمایش یادداشت‌های خاص ارائه شده باشد.

--show-notes[=<ref>], --standard-notes, --no-standard-notes

این گزینه‌ها منسوخ شده‌اند. به‌جای آن‌ها از گزینه‌های --notes/--no-notes فوق استفاده کنید.

--show-signature

اعتبار شیء کامیت امضاشده را با ارسال امضا به gpg --verify بررسی کرده و خروجی را نمایش می‌دهد.

اگر کامیت یک ادغام باشد و چنانچه قالب نمایشی یکی از موارد oneline، email یا raw نباشد، یک خط اضافی پیش از خط Author: درج می‌شود. این خط با "Merge: " آغاز شده و هش‌های کامیت‌های نیاکان با فاصله چاپ می‌شوند. توجه داشته باشید اگر نمای خود از تاریخچه را محدود کرده باشید (برای نمونه تنها به تغییرات مربوط به یک دایرکتوری یا فایل خاص علاقه‌مند باشید)، کامیت‌های فهرست‌شده لزوماً همان فهرست کامیت‌های والد مستقیم نیستند.

چندین قالب توکار وجود دارد، و شما می‌توانید قالب‌های بیشتری را با تنظیم گزینه پیکربندی pretty.<name> روی یک نام قالب دیگر یا یک رشته format: مطابق توضیحات زیر تعریف کنید (به git-config(1) مراجعه کنید). جزئیات قالب‌های توکار به شرح زیر است:

oneline

<hash> <title-line>

این قالب به‌گونه‌ای طراحی شده است که تا حد امکان فشرده باشد.

short

commit <hash>
Author: <author>
    <title-line>

medium

commit <hash>
Author: <author>
Date:   <author-date>
    <title-line>
    <full-commit-message>

full

commit <hash>
Author: <author>
Commit: <committer>
    <title-line>
    <full-commit-message>

fuller

commit <hash>
Author:     <author>
AuthorDate: <author-date>
Commit:     <committer>
CommitDate: <committer-date>
     <title-line>
     <full-commit-message>

reference

<abbrev-hash> (<title-line>, <short-author-date>)

این قالب برای ارجاع به یک کامیت دیگر در پیام کامیت استفاده می‌شود و مشابه --pretty='format:%C(auto)%h (%s, %ad)' است. به‌طور پیش‌فرض، تاریخ با --date=short قالب‌بندی می‌شود مگر اینکه گزینه --date دیگری صراحتاً مشخص شده باشد. همانند هر format: دارای جانگهدارنده‌های قالب، خروجی آن تحت تأثیر گزینه‌های دیگری مانند --decorate و --walk-reflogs قرار نمی‌گیرد.

email

From <hash> <date>
From: <author>
Date: <author-date>
Subject: [PATCH] <title-line>
<full-commit-message>

mboxrd

مشابه email است، اما خطوطی در پیام کامیت که با "From " شروع می‌شوند (با صفر یا چند علامت ">" در ابتدا) با ">" نقل‌قول می‌شوند تا به‌عنوان شروع یک کامیت جدید اشتباه گرفته نشوند.

raw

قالب raw کل کامیت را دقیقاً همان‌گونه که در شیء کامیت ذخیره شده است نشان می‌دهد. به‌ویژه، هش‌ها صرف‌نظر از اینکه از --abbrev یا --no-abbrev استفاده شده باشد، به‌طور کامل نمایش داده می‌شوند، و اطلاعات parents کامیت‌های والد واقعی را بدون در نظر گرفتن پیوندها (grafts) یا ساده‌سازی تاریخچه نشان می‌دهد. توجه داشته باشید که این قالب بر نحوه نمایش کامیت‌ها تأثیر می‌گذارد، اما بر نحوه نمایش diff (برای نمونه با git log --raw) تأثیری ندارد. برای دریافت نام‌های کامل اشیاء در یک قالب diff خام، از --no-abbrev استفاده کنید.

format:<format-string>

قالب format:<format-string> به شما امکان می‌دهد اطلاعاتی را که مایل به نمایش آن هستید مشخص نمایید. عملکرد آن تا حدودی شبیه قالب printf است، با این استثنای قابل توجه که خط جدید را با %n به‌جای \n دریافت می‌کنید.

برای نمونه، format:"The author of %h was %an, %ar%nThe title was >>%s<<%n" خروجی شبیه به این نمایش می‌دهد:

The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<

جانگهدارنده‌ها (placeholders) عبارتند از:

•جانگهدارنده‌هایی که به یک نویسه لفظی (literal) منفرد تبدیل می‌شوند:

%n

خط جدید (newline)

%%

یک % خام

%x00

%x به همراه دو رقم هگزادسیمال با بایتی به ارزش آن ارقام هگزادسیمال جایگزین می‌شود (در ادامه این سند، این مورد را «کد قالب‌بندی لفظی» می‌نامیم).
•جانگهدارنده‌هایی که بر قالب‌بندی جانگهدارنده‌های بعدی تأثیر می‌گذارند:

%Cred

تغییر رنگ به قرمز

%Cgreen

تغییر رنگ به سبز

%Cblue

تغییر رنگ به آبی

%Creset

بازنشانی رنگ

%C(<spec>)

مشخصات رنگ، مطابق توضیحات زیر عنوان Values در بخش "CONFIGURATION FILE" از git-config(1). به‌طور پیش‌فرض، رنگ‌ها تنها در صورتی نمایش داده می‌شوند که برای خروجی لاگ فعال شده باشند (توسط color.diff, color.ui, یا --color, و با رعایت تنظیمات auto موارد پیشین در صورت ارسال به ترمینال). %C(auto,<spec>) به‌عنوان یک مترادف تاریخی برای مقدار پیش‌فرض پذیرفته می‌شود (برای نمونه، %C(auto,red)). مشخص کردن %C(always,<spec>) رنگ‌ها را حتی در صورتی که رنگ به نحو دیگری فعال نشده باشد نشان می‌دهد (اگرچه استفاده از --color=always را برای فعال‌سازی رنگ برای کل خروجی، شامل این قالب و هر چیز دیگری که گیت ممکن است رنگ‌آمیزی کند، در نظر بگیرید). عبارت auto به تنهایی (یعنی %C(auto)) رنگ‌آمیزی خودکار را روی جانگهدارنده‌های بعدی فعال می‌کند تا زمانی که رنگ مجدداً تغییر یابد.

%m

علامت چپ (<)، راست (>) یا مرز (-)

%w([<w>[,<i1>[,<i2>]]])

تغییر پیچش خط (line wrapping)، مشابه گزینه -w از git-shortlog(1).

%<(<n>[,(trunc|ltrunc|mtrunc)])

باعث می‌شود جانگهدارنده بعدی حداقل N پهنای ستون را اشغال کند و در صورت لزوم فاصله‌ها را در سمت راست پر نماید. در صورت تمایل، اگر خروجی طولانی‌تر از <n> ستون باشد، آن را با سه‌نقطه (..) در سمت چپ (ltrunc) ..ft, در وسط (mtrunc) mi..le, یا در انتها (trunc) rig.. کوتاه می‌کند. نکته ۱: کوتاه‌سازی تنها با <n> >= 2 به درستی کار می‌کند. نکته ۲: فاصله‌های اطراف مقادیر <n> و <m> (در ادامه ببینید) اختیاری هستند. نکته ۳: ایموجی‌ها و سایر نویسه‌های پهن دو ستون نمایش را اشغال می‌کنند که ممکن است از مرزهای ستون فراتر رود. نکته ۴: علائم ترکیبی نویسه‌های تفکیک‌شده ممکن است در مرزهای لایه پرکننده (padding) جابه‌جا شوند.

%<|(<m> )

باعث می‌شود جانگهدارنده بعدی حداقل تا <m>-امین ستون نمایش امتداد یابد و در صورت لزوم فاصله‌ها را در سمت راست پر کند. از مقادیر منفی <m> برای موقعیت ستون‌های اندازه‌گیری‌شده از لبه سمت راست پنجره ترمینال استفاده کنید.

%>(<n>), %>|(<m>)

به ترتیب مشابه %<(<n>) و %<|(<m>) هستند، اما فاصله‌ها را در سمت چپ پر می‌کنند.

%>>(<n>), %>>|(<m>)

به ترتیب مشابه %>(<n>) و %>|(<m>) هستند، با این تفاوت که اگر جانگهدارنده بعدی فضایی بیش از مقدار داده‌شده اشغال کند و در سمت چپ آن فاصله وجود داشته باشد، از آن فاصله‌ها استفاده می‌کند.

%><(<n>), %><|(<m>)

به ترتیب مشابه %<(<n>) و %<|(<m>) هستند، اما در هر دو طرف فاصله پر می‌کنند (یعنی متن وسط‌چین می‌شود).
•جانگهدارنده‌هایی که به اطلاعات استخراج‌شده از کامیت بسط می‌یابند:

%H

هش کامیت

%h

هش کوتاه‌شده کامیت

%T

هش درخت

%t

هش کوتاه‌شده درخت

%P

هش‌های والد

%p

هش‌های کوتاه‌شده والد

%an

نام نویسنده

%aN

نام نویسنده (با رعایت .mailmap، به git-shortlog(1) یا git-blame(1) مراجعه کنید)

%ae

ایمیل نویسنده

%aE

ایمیل نویسنده (با رعایت .mailmap، به git-shortlog(1) یا git-blame(1) مراجعه کنید)

%al

بخش محلی ایمیل نویسنده (بخش پیش از علامت @)

%aL

بخش محلی نویسنده (به %al مراجعه کنید) با رعایت .mailmap (به git-shortlog(1) یا git-blame(1) مراجعه فرمایید)

%ad

تاریخ نویسنده (قالب از گزینه --date= پیروی می‌کند)

%aD

تاریخ نویسنده، به سبک RFC2822

%ar

تاریخ نویسنده، نسبی

%at

تاریخ نویسنده، برچسب زمان UNIX

%ai

تاریخ نویسنده، قالب شبیه به ISO 8601

%aI

تاریخ نویسنده، قالب سخت‌گیرانه ISO 8601

%as

تاریخ نویسنده، قالب کوتاه (YYYY-MM-DD)

%ah

تاریخ نویسنده، سبک انسان‌خوان (مانند گزینه --date=human از git-rev-list(1))

%cn

نام کامیت‌کننده (ثبت‌کننده)

%cN

نام کامیت‌کننده (با رعایت .mailmap، به git-shortlog(1) یا git-blame(1) مراجعه کنید)

%ce

ایمیل کامیت‌کننده

%cE

ایمیل کامیت‌کننده (با رعایت .mailmap، به git-shortlog(1) یا git-blame(1) مراجعه کنید)

%cl

بخش محلی ایمیل کامیت‌کننده (بخش پیش از علامت @)

%cL

بخش محلی کامیت‌کننده (به %cl مراجعه کنید) با رعایت .mailmap (به git-shortlog(1) یا git-blame(1) مراجعه فرمایید)

%cd

تاریخ کامیت‌کننده (قالب از گزینه --date= تبعیت می‌کند)

%cD

تاریخ کامیت‌کننده، به سبک RFC2822

%cr

تاریخ کامیت‌کننده، نسبی

%ct

تاریخ کامیت‌کننده، برچسب زمان UNIX

%ci

تاریخ کامیت‌کننده، قالبی شبیه به ISO 8601

%cI

تاریخ کامیت‌کننده، قالب سخت‌گیرانه ISO 8601

%cs

تاریخ کامیت‌کننده، قالب کوتاه (YYYY-MM-DD)

%ch

تاریخ کامیت‌کننده، سبک انسان‌خوان (مانند گزینه --date=human از git-rev-list(1))

%d

نام‌های ارجاع، مانند گزینه --decorate از git-log(1)

%D

نام‌های ارجاع بدون بسته‌بندی در " (" و ")".

%(count)

شماره یک وصله در یک سری وصله. تنها در --commit-list-format در format-patch استفاده می‌شود.

%(total)

تعداد کل وصله‌ها در یک سری وصله. تنها در --commit-list-format در format-patch استفاده می‌شود.

%(decorate[:<option>,...])

نام‌های ارجاع همراه با تزیینات سفارشی. رشته decorate می‌تواند با دو نقطه و صفر یا چند گزینه جداشده با کاما دنبال شود. مقادیر گزینه‌ها می‌توانند شامل کدهای قالب‌بندی لفظی باشند. این کدها به دلیل نقش کاما (%x2C) و پرانتز بسته (%x29) در نحو گزینه‌ها، باید برای این کاراکترها استفاده شوند.

prefix=<value>

پیش از فهرست نام‌های ارجاع نمایش داده می‌شود. پیش‌فرض " (" است.

suffix=<value>

پس از فهرست نام‌های ارجاع نمایش داده می‌شود. پیش‌فرض ")" است.

separator=<value>

بین نام‌های ارجاع نمایش داده می‌شود. پیش‌فرض ", " است.

pointer=<value>

میان HEAD و شاخه‌ای که به آن اشاره می‌کند (در صورت وجود) نشان داده می‌شود. پیش‌فرض " → " است.

tag=<value>

پیش از نام‌های برچسب نمایش داده می‌شود. پیش‌فرض "tag: " است.

برای نمونه، جهت ایجاد تزیینات بدون پرانتز یا حاشیه‌نویسی برچسب و با فاصله به‌عنوان جداکننده:

%(decorate:prefix=,suffix=,tag=,separator= )

%(describe[:<option>,...])

نام انسان‌خوان، مانند git-describe(1)؛ رشته خالی برای کامیت‌های غیرقابل توصیف. رشته describe می‌تواند با دو نقطه و صفر یا چند گزینه جداشده با کاما دنبال شود. هنگامی که برچسب‌ها همزمان اضافه یا حذف شوند، توصیفات ممکن است ناهماهنگ باشند.

tags[=<bool-value>]

به‌جای بررسی تنها برچسب‌های حاشیه‌نویسی‌شده (annotated)، برچسب‌های سبک‌وزن (lightweight) را نیز بررسی می‌کند.

abbrev=<number>

به‌جای استفاده از تعداد پیش‌فرض ارقام هگزادسیمال (که بر اساس تعداد اشیاء در مخزن متغیر است و به‌طور پیش‌فرض ۷ است) برای نام کوتاه‌شده شیء، از <number> رقم، یا به تعداد ارقام لازم برای تشکیل یک نام شیء منحصربه‌فرد استفاده می‌کند.

match=<pattern>

تنها برچسب‌های منطبق با الگوی <pattern> از glob(7) را با حذف پیشوند refs/tags/ در نظر می‌گیرد.

exclude=<pattern>

برچسب‌های منطبق با الگوی <pattern> از glob(7) را با حذف پیشوند refs/tags/ در نظر نمی‌گیرد.

%S

نام ارجاع ارائه‌شده در خط فرمان که کامیت از طریق آن در دسترس قرار گرفته است (مانند git log --source)، تنها با git log کار می‌کند.

%e

کدگذاری (encoding)

%s

موضوع (subject)

%f

خط موضوع پاکسازی‌شده، مناسب برای نام فایل

%b

بدنه (body)

%B

بدنه خام (موضوع و بدنه بدون شکستگی خط)

%N

یادداشت‌های کامیت (commit notes)

%GG

پیام تأیید خام از GPG برای یک کامیت امضاشده

%G?

نمایش "G" برای یک امضای خوب (معتبر)، "B" برای امضای بد، "U" برای امضای خوب با اعتبار نامشخص، "X" برای امضای خوبی که منقضی شده است، "Y" برای امضای خوبی که با یک کلید منقضی ایجاد شده، "R" برای امضای خوبی که با کلید ابطال‌شده ایجاد گردیده، "E" اگر امضا قابل بررسی نباشد (مانند کلید مفقود) و "N" برای نبود امضا

%GS

نمایش نام امضاکننده برای یک کامیت امضاشده

%GK

نمایش کلید استفاده‌شده برای امضای یک کامیت امضاشده

%GF

نمایش اثر انگشت (fingerprint) کلید استفاده‌شده برای امضای یک کامیت امضاشده

%GP

نمایش اثر انگشت کلید اصلی که زیرکلید آن برای امضای کامیت امضاشده استفاده شده است

%GT

نمایش سطح اعتماد برای کلید استفاده‌شده در امضای کامیت امضاشده

%gD

انتخاب‌گر رِف‌لاگ، برای نمونه، refs/stash@{1} یا refs/stash@{2 minutes ago}؛ قالب از قوانین توضیح داده‌شده برای گزینه -g پیروی می‌کند. بخش پیش از @ نام ارجاع ارائه‌شده در خط فرمان است (بنابراین git log -g refs/heads/master خروجی refs/heads/master@{0} خواهد داد).

%gd

انتخاب‌گر کوتاه‌شده رِف‌لاگ؛ مشابه %gD، اما بخش نام ارجاع برای خوانایی بهتر کوتاه شده است (بنابراین refs/heads/master صرفاً تبدیل به master می‌شود).

%gn

نام هویت رِف‌لاگ

%gN

نام هویت رِف‌لاگ (با رعایت .mailmap، به git-shortlog(1) یا git-blame(1) مراجعه کنید)

%ge

ایمیل هویت رِف‌لاگ

%gE

ایمیل هویت رِف‌لاگ (با رعایت .mailmap، به git-shortlog(1) یا git-blame(1) مراجعه فرمایید)

%gs

موضوع رِف‌لاگ

%(trailers[:<option>,...])

دنباله‌های (trailers) بدنه را به همان شکلی که توسط git-interpret-trailers(1) تفسیر می‌شود نمایش می‌دهد. رشته‌ی trailers می‌تواند با یک دو نقطه و صفر یا چند گزینه جداشده با کاما دنبال شود. اگر گزینه‌ای چندین بار ارائه شود، آخرین مورد اعمال خواهد شد.

key=<key>

تنها دنباله‌های با <key> مشخص‌شده را نشان می‌دهد. تطبیق بدون حساسیت به حروف کوچک و بزرگ انجام می‌شود و دو نقطه انتهایی اختیاری است. اگر گزینه چندین بار داده شود، خطوط دنباله منطبق با هر یک از کلیدها نمایش داده می‌شوند. این گزینه به‌طور خودکار گزینه only را فعال می‌سازد تا خطوط غیردنباله در بلوک دنباله پنهان شوند. در صورت عدم تمایل می‌توان آن را با only=false غیرفعال کرد. برای نمونه، %(trailers:key=Reviewed-by) خطوط دنباله با کلید Reviewed-by را نشان می‌دهد.

only[=<bool>]

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

separator=<sep>

جداکننده درج‌شده میان خطوط دنباله را مشخص می‌سازد. پیش‌فرض نویسه خط جدید (line feed) است. رشته <sep> می‌تواند حاوی کدهای قالب‌بندی لفظی توضیح داده‌شده در بالا باشد. برای استفاده از کاما به‌عنوان جداکننده باید از %x2C استفاده کرد، چرا که در غیر این صورت به‌عنوان گزینه بعدی تجزیه می‌شود. برای نمونه، %(trailers:key=Ticket,separator=%x2C ) تمام خطوط دنباله با کلید Ticket را که با کاما و یک فاصله جدا شده‌اند نشان می‌دهد.

unfold[=<bool>]

به‌گونه‌ای عمل می‌کند که گویی گزینه --unfold دستور interpret-trailers داده شده است. برای نمونه، %(trailers:only,unfold=true) تمام خطوط دنباله را باز کرده و نمایش می‌دهد.

keyonly[=<bool>]

تنها بخش کلید دنباله را نشان می‌دهد.

valueonly[=<bool>]

تنها بخش مقدار دنباله را نشان می‌دهد.

key_value_separator=<sep>

جداکننده درج‌شده میان کلید و مقدار هر دنباله را مشخص می‌کند. پیش‌فرض ": " است. در غیر این صورت دارای همان معناشناسی separator=<sep> فوق است.

نکته
برخی از جانگهدارنده‌ها ممکن است به گزینه‌های دیگری که به موتور پیمایش بازنگری داده شده‌اند وابسته باشند. برای نمونه، گزینه‌های رِف‌لاگ %g* رشته‌ای خالی درج خواهند کرد مگر اینکه در حال پیمایش مدخل‌های رِف‌لاگ باشیم (برای مثال با git log -g). جانگهدارنده‌های %d و %D در صورتی که --decorate از قبل در خط فرمان ارائه نشده باشد، از قالب تزیین "short" استفاده خواهند کرد.
گزینه‌های بولی (boolean) یک مقدار اختیاری [=<bool-value>] را می‌پذیرند. مقادیری که توسط --type=bool در git-config(1) مانند yes و off پذیرفته می‌شوند، همگی مجاز هستند. ارائه یک گزینه بولی بدون =<value> معادل ارائه آن با =true است.

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

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

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

tformat:

قالب tformat: دقیقاً مانند format: عمل می‌کند، به جز اینکه به‌جای معناشناسی «جداکننده» (separator)، معناشناسی «پایان‌دهنده» (terminator) را فراهم می‌سازد. به عبارت دیگر، نویسه پایان‌دهنده پیام (معمولاً خط جدید) به هر کامیت اضافه می‌شود، به‌جای اینکه جداکننده‌ای میان مدخل‌ها قرار گیرد. این بدان معناست که مدخل نهایی یک قالب تک‌خطی به درستی با یک خط جدید پایان می‌یابد، درست همانند کاری که قالب "oneline" انجام می‌دهد. برای نمونه:
$ git log -2 --pretty=format:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973 -- NO NEWLINE
$ git log -2 --pretty=tformat:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973

علاوه بر این، هر رشته ناشناخته‌ای که شامل یک % باشد به‌گونه‌ای تفسیر می‌شود که گویی tformat: در ابتدای آن قرار دارد. برای نمونه، این دو مورد معادل هستند:

$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef

گزینه‌های زیر را می‌توان برای تغییر نحوه‌ی تولید خروجی تفاضل (diff) توسط git show به کار برد.

-p, -u, --patch

تولید وصله (بخش موسوم به “GENERATING PATCH TEXT WITH -P” را ببینید).

-s, --no-patch

فرونشاندن تمام خروجی‌های موتور تفاضل. برای دستوراتی مانند git show که به‌طور پیش‌فرض وصله را نشان می‌دهند جهت خاموش کردن خروجی آن‌ها، یا لغو اثر گزینه‌هایی مانند --patch و --stat که پیش‌تر در خط فرمان درون یک نام مستعار (alias) آمده‌اند مفید است.

-m

نمایش تفاضل‌ها برای کامیت‌های ادغام در قالب پیش‌فرض. این مشابه --diff-merges=on است، با این تفاوت که -m هیچ خروجی‌ای تولید نخواهد کرد مگر اینکه -p نیز همراه آن داده شود.

-c

تولید خروجی تفاضل ترکیبی (combined diff) برای کامیت‌های ادغام. میان‌بری برای --diff-merges=combined -p.

--cc

تولید خروجی تفاضل ترکیبی فشرده (dense combined diff) برای کامیت‌های ادغام. میان‌بری برای --diff-merges=dense-combined -p.

--dd

تولید تفاضل نسبت به والد اول برای هر دو کامیت‌های ادغام و معمولی. میان‌بری برای --diff-merges=first-parent -p.

--remerge-diff

تولید خروجی remerge-diff برای کامیت‌های ادغام. میان‌بری برای --diff-merges=remerge -p.

--no-diff-merges

مترادفی برای --diff-merges=off.

--diff-merges=<format>

قالب تفاضل مورد استفاده برای کامیت‌های ادغام را مشخص می‌کند. مقدار پیش‌فرض dense-combined است مگر اینکه --first-parent در حال استفاده باشد، که در این صورت first-parent پیش‌فرض خواهد بود.

قالب‌های زیر پشتیبانی می‌شوند:

off, none

غیرفعال کردن خروجی تفاضل‌ها برای کامیت‌های ادغام. برای لغو مقدار ضمنی مفید است.

on, m

باعث می‌شود خروجی تفاضل برای کامیت‌های ادغام در قالب پیش‌فرض نمایش یابد. قالب پیش‌فرض را می‌توان با متغیر پیکربندی log.diffMerges تغییر داد که مقدار پیش‌فرض آن separate است.

first-parent, 1

نمایش تفاضل کامل نسبت به والد اول. این همان قالبی است که --patch برای کامیت‌های غیرادغام تولید می‌کند.

separate

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

combined, c

نمایش هم‌زمان تفاوت‌ها از هر یک از والدین تا نتیجه ادغام، به‌جای نمایش جفت‌به‌جفت تفاضل بین یک والد و نتیجه به‌صورت تک‌تک. علاوه بر این، تنها فایل‌هایی را فهرست می‌کند که نسبت به تمام والدین تغییر کرده باشند.

dense-combined, cc

فشرده‌سازی بیشتر خروجی تولیدشده توسط --diff-merges=combined با حذف تکه‌های (hunks) نامهم؛ تکه‌هایی که محتوای آن‌ها در والدین تنها دو حالت مختلف دارد و نتیجه‌ی ادغام یکی از آن‌ها را بدون تغییر برمی‌گزیند.

remerge, r

ادغام مجدد کامیت‌های ادغام دو والدی برای ایجاد یک شیء درخت (tree object) موقت—که به‌طور بالقوه حاوی فایل‌هایی با نشانگرهای تعارض و مانند آن است. سپس تفاضلی میان آن درخت موقت و کامیت ادغام واقعی نمایش داده می‌شود.

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

--combined-all-paths

باعث می‌شود تفاضل‌های ترکیبی (استفاده‌شده برای کامیت‌های ادغام) نام فایل را از تمامی والدین فهرست کنند. بنابراین تنها زمانی تأثیر دارد که --diff-merges=[dense-]combined در حال استفاده باشد، و احتمالاً تنها در صورتی مفید است که تغییر نام فایل تشخیص داده شده باشد (یعنی زمانی که تشخیص تغییر نام یا رونوشت درخواست شده باشد).

-U<n>, --unified=<n>

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

--output=<file>

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

--output-indicator-new=<char>, --output-indicator-old=<char>, --output-indicator-context=<char>

نویسه‌ی مورد استفاده برای نشان دادن خطوط جدید، قدیمی یا زمینه را در وصله‌ی تولیدشده مشخص می‌سازد. این نویسه‌ها به‌طور معمول به‌ترتیب +، - و ' ' هستند.

--raw

برای هر کامیت، خلاصه‌ای از تغییرات را با استفاده از قالب تفاضل خام (raw diff format) نمایش می‌دهد. بخش «RAW OUTPUT FORMAT» در git-diff(1) را ببینید. این با نمایش خود گزارش (log) در قالب خام متفاوت است، که می‌توانید با --format=raw به آن دست یابید.

--patch-with-raw

مترادفی برای -p --raw.

-t

نمایش اشیاء درخت (tree objects) در خروجی تفاضل.

--indent-heuristic

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

--no-indent-heuristic

غیرفعال‌سازی روش اکتشافی دندانه‌گذاری (indent heuristic).

--minimal

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

--patience

تولید تفاضل با استفاده از الگوریتم «patience diff».

--histogram

تولید تفاضل با استفاده از الگوریتم «histogram diff».

--anchored=<text>

تولید تفاضل با استفاده از الگوریتم «anchored diff».

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

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

--diff-algorithm=(patience|minimal|histogram|myers)

انتخاب الگوریتم تفاضل. گونه‌های موجود به شرح زیر هستند:

default, myers

الگوریتم پایه‌ای و حریصانه‌ی تفاضل (greedy diff). در حال حاضر، این حالت پیش‌فرض است.

minimal

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

patience

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

histogram

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

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

--stat[=<width>[,<name-width>[,<count>]]]

تولید یک diffstat. به‌طور پیش‌فرض، تا جای ممکن فضا برای بخش نام فایل و باقی‌مانده آن برای بخش نمودار میله‌ای (graph) استفاده خواهد شد. بیشینه‌ی عرض به‌طور پیش‌فرض برابر با عرض ترمینال، یا ۸۰ ستون در صورت عدم اتصال به ترمینال است و با <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

خروجی دادن خلاصه‌ای فشرده از اطلاعات سرآیند گسترده (extended header) مانند ایجاد یا حذف فایل‌ها ("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 با انجام تحلیل تفاضل خط‌محور معمول، و جمع بستن تعداد خطوط حذف‌شده/افزوده‌شده. (برای فایل‌های باینری، در عوض تکه‌های ۶۴ بایتی شمرده می‌شوند، زیرا فایل‌های باینری مفهوم طبیعی خط را ندارند). این یک رفتار هزینه‌برتر برای --dirstat نسبت به رفتار changes است، اما خطوط بازآرایی‌شده درون یک فایل را به اندازه سایر تغییرات به شمار می‌آورد. خروجی حاصل با آنچه از سایر گزینه‌های --*stat به دست می‌آورید سازگار است.

files

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

cumulative

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

<limit>

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

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

--cumulative

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

--dirstat-by-file[=<param>,...]

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

--summary

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

--patch-with-stat

مترادفی برای -p --stat.

-z

جدا کردن کامیت‌ها با NUL به‌جای خط‌های جدید.

همچنین هنگامی که --raw یا --numstat داده شده باشد، نام مسیرها را دستکاری نکرده و از NUL به‌عنوان پایان‌بخش فیلدهای خروجی استفاده می‌کند.

بدون این گزینه، نام مسیرهای دارای نویسه‌های «نامعمول» طبق آنچه برای متغیر پیکربندی core.quotePath توضیح داده شده است نقل‌قول می‌شوند (نگاه کنید به git-config(1)).

--name-only

تنها نام هر فایل تغییریافته را در درخت تصویر پسین (post-image tree) نشان می‌دهد. نام فایل‌ها اغلب با UTF-8 کدگذاری می‌شوند. برای اطلاعات بیشتر به بحث درباره کدگذاری در صفحه راهنمای git-log(1) مراجعه کنید.

--name-status

تنها نام(ها) و وضعیت هر فایل تغییریافته را نشان می‌دهد. برای آگاهی از معنای حروف وضعیت به توضیحات گزینه --diff-filter مراجعه کنید. همانند --name-only نام فایل‌ها معمولاً با UTF-8 کدگذاری می‌شوند.

--submodule[=<format>]

نحوه نمایش تفاوت‌ها در زیرماژول‌ها را مشخص می‌کند. هنگام تعیین --submodule=short قالب short استفاده می‌شود. این قالب صرفاً نام کامیت‌ها را در ابتدا و انتهای محدوده نشان می‌دهد. هنگامی که --submodule یا --submodule=log مشخص شود، از قالب log استفاده می‌گردد. این قالب کامیت‌های موجود در محدوده را مانند summary از git-submodule(1) فهرست می‌کند. هنگامی که --submodule=diff مشخص شود، از قالب diff استفاده می‌شود. این قالب یک diff درون‌خطی از تغییرات در محتوای زیرماژول میان محدوده کامیت‌ها را نشان می‌دهد. در صورت عدم تنظیم گزینه پیکربندی، به‌طور پیش‌فرض از diff.submodule یا قالب short استفاده می‌کند.

--color[=<when>]

نمایش diff رنگی. --color (یعنی بدون =<when>) مشابه --color=always است. <when> می‌تواند یکی از موارد always, never یا auto باشد.

--no-color

خاموش کردن diff رنگی. مشابه --color=never است.

--color-moved[=<mode>]

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

no

خطوط جابه‌جاشده برجسته نمی‌شوند.

default

مترادفی برای zebra است. این ممکن است در آینده به یک حالت منطقی‌تر تغییر یابد.

plain

هر خطی که در یک مکان اضافه شده و در مکان دیگری حذف شده باشد، با color.diff.newMoved رنگ‌آمیزی می‌شود. مشابهاً color.diff.oldMoved برای خطوط حذف‌شده‌ای که در جای دیگری در diff اضافه شده‌اند استفاده خواهد شد. این حالت هر خط جابه‌جاشده را شناسایی می‌کند، اما در بازبینی برای تشخیص اینکه آیا یک بلوک کد بدون جابه‌جایی و تغییر ترتیب انتقال یافته است یا خیر چندان مفید نیست.

blocks

بلوک‌های متن جابه‌جاشده با دست‌کم ۲۰ نویسه الفبایی-عددی به‌صورت حریصانه شناسایی می‌شوند. بلوک‌های شناسایی‌شده با رنگ color.diff.(old|new)Moved رنگ‌آمیزی می‌گردند. بلوک‌های مجاور قابل تفکیک از یکدیگر نیستند.

zebra

بلوک‌های متن جابه‌جاشده مانند حالت blocks شناسایی می‌شوند. بلوک‌ها با استفاده از رنگ color.diff.(old|new)Moved یا color.diff.(old|new)MovedAlternative رنگ‌آمیزی می‌شوند. تغییر میان این دو رنگ نشان می‌دهد که یک بلوک جدید شناسایی شده است.

dimmed-zebra

مشابه zebra، اما کم‌رنگ‌سازی بیشتر بخش‌های نامهم کد جابه‌جاشده انجام می‌شود. خطوط مرزی دو بلوک مجاور مهم تلقی شده و بقیه نامهم در نظر گرفته می‌شوند. dimmed_zebra یک مترادف منسوخ‌شده است.

--no-color-moved

خاموش کردن تشخیص جابه‌جایی. این را می‌توان برای بازنویسی تنظیمات پیکربندی استفاده کرد. مشابه --color-moved=no است.

--color-moved-ws=<mode>,...

نحوه نادیده گرفتن فاصله‌های خالی را هنگام انجام تشخیص جابه‌جایی برای --color-moved پیکربندی می‌کند. این حالت‌ها را می‌توان به‌صورت فهرستی جداشده با کاما مشخص کرد:

no

فاصله‌های خالی را هنگام انجام تشخیص جابه‌جایی نادیده نگیرد.

ignore-space-at-eol

تغییرات در فاصله‌های خالی در انتهای خط (EOL) را نادیده بگیرد.

ignore-space-change

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

ignore-all-space

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

allow-indentation-change

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

--no-color-moved-ws

فاصله‌های خالی را هنگام انجام تشخیص جابه‌جایی نادیده نگیرد. این را می‌توان برای لغو تنظیمات پیکربندی استفاده کرد. مشابه --color-moved-ws=no است.

--word-diff[=<mode>]

به‌طور پیش‌فرض، کلمات با فاصله خالی از هم جدا می‌شوند؛ به --word-diff-regex در ادامه مراجعه کنید. مقدار <mode> به‌طور پیش‌فرض plain است و باید یکی از موارد زیر باشد:

color

برجسته‌سازی کلمات تغییریافته تنها با استفاده از رنگ‌ها. متضمن --color است.

plain

نمایش کلمات به‌صورت [-removed-] و {added}. هیچ تلاشی برای اسکیپ کردن جداکننده‌ها در صورت ظاهر شدن در ورودی انجام نمی‌دهد، بنابراین ممکن است خروجی مبهم باشد.

porcelain

استفاده از یک قالب خطی ویژه که برای پردازش توسط اسکریپت‌ها در نظر گرفته شده است. توالی‌های اضافه‌شده/حذف‌شده/تغییرنیافته در قالب معمول diff یکپارچه چاپ می‌شوند که با یک نویسه +/-/` ` در ابتدای خط آغاز شده و تا انتهای خط امتداد می‌یابد. خطوط جدید در ورودی با یک مدک ~ در یک خط مستقل نمایش داده می‌شوند.

none

غیرفعال کردن مجدد word diff.

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

گزینه --word-diff با گرفتن همان diff خط به خط تولیدشده بدون این گزینه و محاسبه تغییرات کلمه به کلمه در هر قطعه عمل می‌کند. این ممکن است تفاوتی بزرگتر از آنچه یک ابزار اختصاصی word-diff تولید می‌کند ایجاد کند. اگر گیت در آینده پیاده‌سازی متفاوتی به دست آورد، ممکن است خروجی تغییر کند. توجه داشته باشید که این مشابه گزینه --diff-algorithm است که ممکن است خروجی را نیز تغییر دهد.

--word-diff-regex=<regex>

استفاده از <regex> برای تصمیم‌گیری درباره اینکه کلمه چیست، به‌جای اینکه توالی‌های غیرفاصله خالی یک کلمه در نظر گرفته شوند. همچنین متضمن --word-diff است مگر اینکه از قبل فعال شده باشد.

هر تطابق غیرهمپوشان از <regex> یک کلمه تلقی می‌شود. هر چیزی بین این تطابق‌ها فاصله خالی در نظر گرفته شده و به منظور یافتن تفاوت‌ها نادیده گرفته می‌شود(!). ممکن است بخواهید |[^[:space:]] را به عبارت باقاعده خود اضافه کنید تا مطمئن شوید با تمام نویسه‌های غیرفاصله خالی تطابق دارد. تطابقی که حاوی یک خط جدید باشد، بدون اعلام خطا در محل خط جدید کوتاه می‌شود(!).

برای نمونه، --word-diff-regex=. با هر نویسه مانند یک کلمه رفتار می‌کند و متناظراً تفاوت‌ها را نویسه به نویسه نشان می‌دهد.

عبارت باقاعده را می‌توان از طریق درایور diff یا گزینه پیکربندی نیز تنظیم کرد، به gitattributes(5) یا git-config(1) مراجعه کنید. تعیین صریح آن بر هر درایور diff یا تنظیم پیکربندی اولویت دارد. درایورهای diff بر تنظیمات پیکربندی اولویت دارند.

--color-words[=<regex>]

معادل --word-diff=color به همراه (در صورت مشخص شدن یک عبارت باقاعده) --word-diff-regex=<regex> است.

--no-renames

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

--rename-empty, --no-rename-empty

آیا از blobهای خالی به‌عنوان مبدأ تغییر نام استفاده شود یا خیر.

--check

هشدار در صورتی که تغییرات نشانگرهای تعارض یا خطاهای فاصله خالی (whitespace errors) ایجاد کنند. آنچه خطای فاصله خالی محسوب می‌شود توسط پیکربندی core.whitespace کنترل می‌گردد. به‌طور پیش‌فرض، فاصله‌های خالی انتهایی (شامل خطوطی که منحصراً از فاصله‌های خالی تشکیل شده‌اند) و نویسه فاصله‌ای که بلافاصله پس از آن نویسه تب در تورفتگی ابتدایی خط قرار گرفته باشد، خطای فاصله خالی در نظر گرفته می‌شوند. در صورت یافتن مشکل، با وضعیت غیرصفر خارج می‌شود. با --exit-code سازگار نیست.

--ws-error-highlight=<kind>

برجسته‌سازی خطاهای فاصله خالی در خطوط context, old یا new مربوط به diff. مقادیر چندگانه با ویرگول جدا می‌شوند، none مقادیر قبلی را بازنشانی می‌کند، default فهرست را به new بازنشانی می‌نماید و all یک کوتاه‌نویسی برای old,new,context است. هنگامی که این گزینه داده نشود و متغیر پیکربندی diff.wsErrorHighlight تنظیم نشده باشد، تنها خطاهای فاصله خالی در خطوط new برجسته می‌شوند. خطاهای فاصله خالی با رنگ color.diff.whitespace نمایش داده می‌شوند.

--full-index

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

--binary

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

--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 را کنترل می‌کند (پیش‌فرض ۶۰٪ است). -B/70% مشخص می‌کند که کمتر از ۳۰٪ از نسخه اصلی باید در نتیجه باقی بماند تا گیت آن را یک بازنویسی کامل در نظر بگیرد (در غیر این صورت وصله حاصل مجموعه‌ای از حذف و درج‌های مخلوط با خطوط زمینه خواهد بود).

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

-M[<n>], --find-renames[=<n>]

در صورت تولید diff، تغییر نام‌ها را برای هر کامیت تشخیص داده و گزارش می‌دهد. برای دنبال کردن فایل‌ها در سراسر تغییر نام‌ها هنگام پیمایش تاریخچه، به --follow مراجعه فرمایید. اگر <n> مشخص شود، یک آستانه روی شاخص شباهت است (یعنی مقدار افزودن/حذف‌ها در مقایسه با اندازه فایل). برای نمونه، -M90% به این معنی است که گیت باید یک جفت حذف/افزودن را در صورتی یک تغییر نام در نظر بگیرد که بیش از ۹۰٪ فایل تغییر نکرده باشد. بدون علامت %، عدد به‌عنوان یک کسر با ممیز در ابتدای آن خوانده می‌شود؛ یعنی -M5 تبدیل به 0.5 می‌شود و بنابراین همان -M50% است. مشابهاً، -M05 مشابه -M5% است. برای محدود کردن تشخیص به تغییر نام‌های دقیق، از -M100% استفاده کنید. شاخص شباهت پیش‌فرض ۵۰٪ است.

-C[<n>], --find-copies[=<n>]

تشخیص رونوشت‌ها (copies) و همچنین تغییر نام‌ها. همچنین به --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 به‌عنوان نامحدود در نظر گرفته می‌شود.

--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]

تنها فایل‌هایی را انتخاب می‌کند که افزوده‌شده (A)، رونوشت‌برداری‌شده (C)، حذف‌شده (D)، اصلاح‌شده (M)، تغییرنام‌یافته (R)، نوع آن‌ها (مانند فایل معمولی، پیوند نمادین، زیرماژول و غیره) تغییر کرده (T)، ادغام‌نشده (U)، ناشناخته (X)، یا پیوند آن‌ها شکسته شده باشد (B). هر ترکیبی از نویسه‌های فیلتر (شامل هیچ‌کدام) می‌تواند استفاده شود. هنگامی که * (همه یا هیچ) به ترکیب اضافه شود، در صورتی که فایلی منطبق با سایر معیارها در مقایسه وجود داشته باشد، تمام مسیرها انتخاب می‌شوند؛ اگر هیچ فایلی منطبق با سایر معیارها نباشد، هیچ چیزی انتخاب نمی‌شود.

همچنین، این حروف بزرگ را می‌توان با حروف کوچک برای استثنا کردن نوشت. برای نمونه --diff-filter=ad مسیرهای افزوده‌شده و حذف‌شده را مستثنی می‌سازد.

توجه داشته باشید که همه diffها نمی‌توانند تمام انواع را نشان دهند. برای مثال، ورودی‌های رونوشت‌برداری‌شده و تغییرنام‌یافته در صورتی که تشخیص برای آن انواع غیرفعال باشد نمی‌توانند ظاهر شوند.

-S<string>

به دنبال تفاوت‌هایی می‌گردد که تعداد رخدادهای <string> مشخص‌شده (یعنی افزودن/حذف) را در یک فایل تغییر می‌دهند. برای استفاده اسکریپت‌نویسان در نظر گرفته شده است.

زمانی مفید است که به دنبال یک بلوک دقیق از کد (مانند یک struct) می‌گردید و می‌خواهید تاریخچه آن بلوک را از زمان ایجاد اولیه بدانید: از این ویژگی به‌صورت تکراری استفاده کنید تا بلوک مورد نظر در تصویر پیشین را مجدداً به -S ارسال کنید، و این کار را ادامه دهید تا به نخستین نسخه بلوک برسید.

فایل‌های باینری نیز جستجو می‌شوند. -G<regex>

به دنبال تفاوت‌هایی می‌گردد که متن وصله (patch) آن‌ها شامل خطوط اضافه‌شده/حذف‌شده‌ای باشد که با <regex> مطابقت دارند.

برای نشان دادن تفاوت بین -S<regex> --pickaxe-regex و -G<regex>، کامیتی با تفاوت‌های زیر در همان فایل را در نظر بگیرید:

+    return frotz(nitfol, two->ptr, 1, 0);
...
-    hit = frotz(nitfol, mf2.ptr, 1, 0);

در حالی که دستور git log -G"frotz\(nitfol" این کامیت را نمایش می‌دهد، دستور git log -S"frotz\(nitfol" --pickaxe-regex آن را نشان نخواهد داد (زیرا تعداد دفعات تکرار آن رشته تغییر نکرده است).

مگر اینکه --text مشخص شده باشد، وصله‌های فایل‌های باینری بدون فیلتر textconv نادیده گرفته می‌شوند.

برای اطلاعات بیشتر به مدخل pickaxe در gitdiffcore(7) مراجعه کنید.

--find-object=<object-id>

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

این شیء می‌تواند یک blob یا یک کامیت زیرماژول باشد. این گزینه مستلزم گزینه -t در git-log است تا درخت‌ها را نیز پیدا کند.

--pickaxe-all

هنگامی که -S یا -G تغییری را پیدا کرد، تمام تغییرات موجود در آن مجموعه تغییرات (changeset) را نشان می‌دهد، نه فقط فایل‌هایی که حاوی تغییر در <string> هستند.

--pickaxe-regex

با <string> داده‌شده به -S به عنوان یک عبارت باقاعده گسترده POSIX برای تطبیق رفتار می‌کند.

-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> نام‌برده‌شده را از خروجی کنار می‌گذارد (یعنی skip to)، یا آن‌ها را به انتهای خروجی منتقل می‌کند (یعنی rotate to). این گزینه‌ها در اصل برای استفاده در دستور git difftool طراحی شده‌اند و در غیر این صورت ممکن است کاربرد چندانی نداشته باشند.

-R

دو ورودی را جابه‌جا می‌کند؛ به این معنا که تفاوت‌ها را از نمایه (index) یا فایل روی دیسک به محتوای درخت نشان می‌دهد.

--relative[=<path>], --no-relative

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

-a, --text

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

--ignore-cr-at-eol

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

--ignore-space-at-eol

تغییرات در فاصله‌های خالی (whitespace) در انتهای خط (EOL) را نادیده می‌گیرد.

-b, --ignore-space-change

تغییرات در میزان فاصله‌های خالی را نادیده می‌گیرد. این گزینه فاصله‌های خالی در انتهای خط را نادیده می‌گیرد و سایر توالی‌های یک یا چند نویسه فاصله خالی را معادل یکدیگر در نظر می‌گیرد.

-w, --ignore-all-space

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

--ignore-blank-lines

تغییراتی که تمام خطوط آن‌ها خالی است را نادیده می‌گیرد.

-I<regex>, --ignore-matching-lines=<regex>

تغییراتی که تمام خطوط آن‌ها با <regex> مطابقت دارد را نادیده می‌گیرد. این گزینه می‌تواند بیش از یک بار مشخص شود.

--inter-hunk-context=<number>

بافت (context) بین تکه‌های تفاوت (diff hunks) را تا <number> خط مشخص‌شده نمایش می‌دهد، و بدین ترتیب تکه‌هایی را که به یکدیگر نزدیک هستند به هم پیوند می‌دهد. مقدار پیش‌فرض diff.interHunkContext یا در صورت تنظیم نشدن گزینه پیکربندی برابر 0 است.

-W, --function-context

کل تابع را به عنوان خطوط بافت برای هر تغییر نمایش می‌دهد. نام توابع به همان شیوه‌ای تعیین می‌شوند که git diff هدر تکه‌های وصله را استخراج می‌کند (به «Defining a custom hunk-header» در 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) یا دستورات لوله‌کشی (plumbing) diff فعال نمی‌باشند.

--ignore-submodules[=(none|untracked|dirty|all)]

تغییرات زیرماژول‌ها را در تولید diff نادیده می‌گیرد. all مقدار پیش‌فرض است. استفاده از none در صورتی که زیرماژول حاوی فایل‌های ردگیری‌نشده یا تغییریافته باشد یا مقدار HEAD آن با کامیت ثبت‌شده در پروژه بالادست (superproject) تفاوت داشته باشد، زیرماژول را تغییریافته در نظر می‌گیرد و می‌تواند برای بازنویسی هرگونه تنظیمات گزینه 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/») استفاده می‌کند. این گزینه متغیرهای پیکربندی نظیر diff.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 مشخص نشده باشد، عمق طوری محاسبه می‌شود که گویی تمام ورودی‌های سطح بالا (top-level) مشخص شده‌اند. توجه داشته باشید که این با محاسبه از ریشه متفاوت است، زیرا --max-depth=0 همچنان foo را برمی‌گرداند. این ویژگی به شما اجازه می‌دهد تا عمق را محدود کنید در حالی که زیرمجموعه‌ای از ورودی‌های سطح بالا را درخواست می‌کنید.

توجه داشته باشید که این گزینه فقط برای diff بین اشیاء درخت (tree objects) پشتیبانی می‌شود، نه در برابر نمایه (index) یا درخت کاری (working tree).

برای توضیحات دقیق‌تر درباره این گزینه‌های مشترک، به gitdiffcore(7) نیز مراجعه کنید.

اجرای git-diff(1)، git-log(1)، git-show(1)، git-diff-index(1)، git-diff-tree(1) یا git-diff-files(1) با گزینه -p متن وصله تولید می‌کند. می‌توانید ایجاد متن وصله را از طریق متغیرهای محیطی GIT_EXTERNAL_DIFF و GIT_DIFF_OPTS (به git(1) مراجعه کنید) و صفت diff (به gitattributes(5) مراجعه کنید) سفارشی‌سازی کنید.

آنچه گزینه -p تولید می‌کند کمی با قالب سنتی diff تفاوت دارد:

1.پیش از آن یک هدر "git diff" قرار می‌گیرد که به این صورت است:
diff --git a/file1 b/file2

نام پرونده‌های a/ و b/ یکسان هستند مگر اینکه تغییر نام یا رونوشت در کار باشد. به‌ویژه، حتی برای ایجاد یا حذف یک پرونده، /dev/null به جای نام پرونده‌های a/ یا b/ استفاده نمی‌شود.

هنگامی که تغییر نام یا رونوشت در میان باشد، file1 و file2 به ترتیب نام پرونده مبدا تغییر نام/رونوشت و نام پرونده‌ای را که تغییر نام/رونوشت تولید می‌کند نشان می‌دهند.

2.پس از آن یک یا چند خط هدر گسترده می‌آید:
old mode <mode>
new mode <mode>
deleted file mode <mode>
new file mode <mode>
copy from <path>
copy to <path>
rename from <path>
rename to <path>
similarity index <number>
dissimilarity index <number>
index <hash>..<hash> <mode>

حالت‌های پرونده <mode> به عنوان اعداد اکتال ۶ رقمی شامل نوع پرونده و بیت‌های مجوز پرونده چاپ می‌شوند.

نام مسیرها در هدرهای گسترده شامل پیشوندهای a/ و b/ نیستند.

شاخص شباهت (similarity index) درصد خطوط تغییرنیافته و شاخص عدم شباهت (dissimilarity index) درصد خطوط تغییریافته است. این مقدار یک عدد صحیح گرد شده به سمت پایین است که پس از آن علامت درصد می‌آید. بنابراین مقدار شاخص شباهت ۱۰۰٪ برای دو پرونده یکسان اختصاص دارد، در حالی که ۱۰۰٪ عدم شباهت بدین معنی است که هیچ خطی از پرونده قدیمی به پرونده جدید راه نیافته است.

خط index شامل نام اشیاء blob قبل و بعد از تغییر است. اگر حالت پرونده تغییر نکند، <mode> گنجانده می‌شود؛ در غیر این صورت، خطوط جداگانه حالت قدیمی و جدید را مشخص می‌کنند.

3.نام مسیرهایی که دارای نویسه‌های "نامعمول" هستند، همان‌طور که برای متغیر پیکربندی core.quotePath توضیح داده شده است، در نقل‌قول قرار می‌گیرند (به git-config(1) مراجعه کنید).
4.تمام پرونده‌های file1 در خروجی به پرونده‌های پیش از کامیت اشاره دارند، و تمام پرونده‌های file2 به پرونده‌های پس از کامیت اشاره دارند. اعمال متوالی هر تغییر به هر پرونده نادرست است. برای نمونه، این وصله a و b را با هم جابه‌جا (swap) می‌کند:
diff --git a/a b/b
rename from a
rename to b
diff --git a/b b/a
rename from b
rename to a
5.هدرهای قطعه (Hunk headers) نام تابعی را که قطعه به آن اعمال می‌شود ذکر می‌کنند. برای جزئیات نحوه سفارشی‌سازی این مورد برای زبان‌های خاص، به "Defining a custom hunk-header" در gitattributes(5) مراجعه کنید.

هر دستور تولیدکننده تفاضل می‌تواند گزینه -c یا --cc را برای تولید یک تفاضل ترکیبی (combined diff) هنگام نمایش یک ادغام دریافت کند. این قالب پیش‌فرض هنگام نمایش ادغام‌ها با git-diff(1) یا git-show(1) است. همچنین توجه داشته باشید که می‌توانید گزینه مناسب --diff-merges را به هر یک از این دستورات بدهید تا تولید تفاضل‌ها را در یک قالب مشخص اجبار کند.

یک قالب "تفاضل ترکیبی" به این شکل است:

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
        return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }
- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +      unsigned char sha1[20];
 +      struct commit *cmit;
        struct commit_list *list;
        static int initialized = 0;
        struct commit_name *n;
 +      if (get_sha1(arg, sha1) < 0)
 +              usage(describe_usage);
 +      cmit = lookup_commit_reference(sha1);
 +      if (!cmit)
 +              usage(describe_usage);
 +
        if (!initialized) {
                initialized = 1;
                for_each_ref(get_name);
1.پیش از آن یک هدر "git diff" قرار می‌گیرد، که شبیه به این است (زمانی که گزینه -c استفاده شود):
diff --combined file

یا شبیه به این (زمانی که گزینه --cc استفاده شود):

diff --cc file
2.پس از آن یک یا چند خط هدر گسترده می‌آید (این مثال یک ادغام با دو والد را نشان می‌دهد):
index <hash>,<hash>..<hash>
mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>

خط mode <mode>,<mode>..<mode> تنها زمانی ظاهر می‌شود که دست‌کم یکی از <mode>ها با بقیه متفاوت باشد. هدرهای گسترده با اطلاعات مربوط به جابه‌جایی محتوای شناسایی‌شده (تشخیص تغییر نام و رونوشت) برای کار با تفاضل دو <tree-ish> طراحی شده‌اند و در قالب تفاضل ترکیبی استفاده نمی‌شوند.

3.پس از آن یک هدر دوخطی from-file/to-file می‌آید:
--- a/file
+++ b/file

مشابه با هدر دوخطی برای قالب سنتی تفاضل یکپارچه (unified)، از /dev/null برای نشان دادن پرونده‌های ایجادشده یا حذف‌شده استفاده می‌شود.

با این حال، اگر گزینه --combined-all-paths ارائه شده باشد، به جای یک هدر دوخطی from-file/to-file، یک هدر N+1 خطی from-file/to-file دریافت می‌کنید، که در آن N تعداد والدهای موجود در کامیت ادغام است:

--- a/file
--- a/file
--- a/file
+++ b/file

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

4.قالب هدر قطعه (Chunk header) تغییر یافته است تا از ارسال تصادفی آن توسط افراد به patch -p1 جلوگیری شود. قالب تفاضل ترکیبی برای بازبینی تغییرات کامیت ادغام ایجاد شده است، و قرار نبوده که اعمال شود. این تغییر شبیه به تغییر در هدر گسترده index است:
@@@ <from-file-range> <from-file-range> <to-file-range> @@@

در هدر قطعه برای قالب تفاضل ترکیبی تعداد (تعداد والدها + ۱) نویسه @ وجود دارد.

برخلاف قالب سنتی تفاضل یکپارچه (unified) که دو پرونده A و B را با یک ستون تکی نشان می‌دهد که دارای پیشوند - (منفی — در A وجود دارد اما در B حذف شده)، + (مثبت — در A نیست اما به B اضافه شده)، یا " " (فاصله — بدون تغییر) است، این قالب دو یا چند پرونده file1، file2،... را با یک پرونده X مقایسه می‌کند و نشان می‌دهد چگونه X با هر یک از fileNها تفاوت دارد. یک ستون به ازای هر یک از fileN به ابتدای خط خروجی افزوده می‌شود تا نشان دهد خط X چگونه با آن تفاوت دارد.

یک نویسه - در ستون N به این معنی است که آن خط در fileN وجود دارد اما در نتیجه ظاهر نمی‌شود. یک نویسه + در ستون N به این معنی است که آن خط در نتیجه ظاهر می‌شود، و fileN آن خط را ندارد (به عبارت دیگر، خط از دیدگاه آن والد اضافه شده است).

در خروجی مثال بالا، امضای تابع از هر دو پرونده تغییر کرده است (بنابراین دو حذف - از هر دو پرونده file1 و file2، به علاوه ++ به این معنی که یک خط اضافه شده که در هیچ‌یک از file1 یا file2 ظاهر نمی‌شود). همچنین، هشت خط دیگر از file1 یکسان هستند اما در file2 ظاهر نمی‌شوند (بنابراین با پیشوند + مشخص شده‌اند).

هنگامی که توسط git diff-tree -c نمایش داده می‌شود، والدهای یک کامیت ادغام را با نتیجه ادغام مقایسه می‌کند (یعنی file1..fileN والدها هستند). هنگامی که توسط git diff-files -c نمایش داده می‌شود، دو والد ادغام حل‌نشده را با پرونده درخت کاری مقایسه می‌کند (یعنی file1 استیج ۲ یا همان «نسخه ما»، file2 استیج ۳ یا همان «نسخه آن‌ها» است).

git show v1.0.0

برچسب v1.0.0 را همراه با شیئی که برچسب به آن اشاره می‌کند نمایش می‌دهد.

git show v1.0.0^{tree}

درختی را که برچسب v1.0.0 به آن اشاره می‌کند نمایش می‌دهد.

git show -s --format=%s v1.0.0^{commit}

موضوع کامیت اشاره‌شده توسط برچسب v1.0.0 را نمایش می‌دهد.

git show next~10:Documentation/README

محتویات پرونده Documentation/README را به شکلی که در دهمین کامیت ماقبل آخر شاخه next جاری بود نمایش می‌دهد.

git show master:Makefile master:t/Makefile

محتویات Makefileهای مذکور را در نوک (head) شاخه master پشت سر هم متصل (الحاق) می‌کند.

گیت تا حدودی نسبت به کدگذاری نویسه‌ها (character encoding) بی‌تفاوت (agnostic) است.

•محتویات اشیاء blob توالی‌های تفسیرنشده‌ای از بایت‌ها هستند. هیچ تبدیل کدگذاری در سطح هسته گیت وجود ندارد.
•نام مسیرها در فرم C نرمال‌سازی UTF-8 کدگذاری می‌شوند. این امر برای اشیاء درخت، پرونده نمایه (index)، نام‌های ref، و همچنین نام مسیرها در آرگومان‌های خط فرمان، متغیرهای محیطی و پرونده‌های پیکربندی (.git/config (به git-config(1) مراجعه کنید)، gitignore(5)، gitattributes(5) و gitmodules(5)) اعمال می‌شود.

توجه داشته باشید که گیت در سطح هسته با نام مسیرها صرفاً به عنوان توالی‌هایی از بایت‌های غیر NUL رفتار می‌کند؛ هیچ تبدیل کدگذاری برای نام مسیرها وجود ندارد (به جز در مک و ویندوز). بنابراین، استفاده از نام مسیرهای غیر ASCII حتی روی پلتفرم‌ها و سیستم‌های پرونده‌ای که از کدگذاری‌های قدیمی ASCII توسعه‌یافته استفاده می‌کنند، عمدتاً کار خواهد کرد. با این حال، مخازن ایجادشده روی چنین سیستم‌هایی روی سیستم‌های مبتنی بر UTF-8 (مانند لینوکس، مک، ویندوز) به درستی کار نخواهند کرد و بالعکس. علاوه بر این، بسیاری از ابزارهای مبتنی بر گیت صرفاً فرض می‌کنند که نام مسیرها UTF-8 هستند و در نمایش صحیح سایر کدگذاری‌ها ناموفق خواهند بود.

•پیام‌های لاگ کامیت معمولاً با UTF-8 کدگذاری می‌شوند، اما سایر کدگذاری‌های ASCII توسعه‌یافته نیز پشتیبانی می‌شوند. این شامل ISO-8859-x، CP125x و بسیاری موارد دیگر است، اما نه UTF-16/32، EBCDIC و کدگذاری‌های چندبایتی CJK (مانند GBK، Shift-JIS، Big5، EUC-x، CP9xx و غیره).

اگرچه ما تشویق می‌کنیم که پیام‌های لاگ کامیت با UTF-8 کدگذاری شوند، هسته گیت و ابزارهای لایه کاربری (Git Porcelain) به گونه‌ای طراحی شده‌اند که UTF-8 را به پروژه‌ها تحمیل نکنند. اگر همه مشارکت‌کنندگان یک پروژه خاص استفاده از کدگذاری‌های سنتی را راحت‌تر می‌دانند، گیت آن را منع نمی‌کند. با این حال، چند نکته وجود دارد که باید در نظر داشت.

1.دستورات git commit و git commit-tree در صورتی که پیام لاگ کامیت داده‌شده به آن‌ها شبیه یک رشته معتبر UTF-8 نباشد اخطار صادر می‌کنند، مگر اینکه صریحاً مشخص کنید که پروژه شما از یک کدگذاری سنتی استفاده می‌کند. روش بیان این موضوع داشتن i18n.commitEncoding در پرونده .git/config است، به این صورت:
[i18n]
        commitEncoding = ISO-8859-1

اشیای کامیت ایجادشده با تنظیمات فوق، مقدار i18n.commitEncoding را در هدر encoding خود ثبت می‌کنند. این کار برای کمک به دیگرانی است که بعداً به آن‌ها نگاه می‌کنند. نبود این هدر نشان‌دهنده این است که پیام لاگ کامیت با UTF-8 کدگذاری شده است.

2.دستورات git log، git show، git blame و نظایر آن‌ها به هدر encoding شیء کامیت نگاه می‌کنند و سعی می‌کنند پیام لاگ را به UTF-8 بازکدگذاری (re-code) کنند مگر اینکه خلاف آن مشخص شده باشد. می‌توانید کدگذاری خروجی مورد نظر را با i18n.logOutputEncoding در پرونده .git/config مشخص کنید، به این صورت:
[i18n]
        logOutputEncoding = ISO-8859-1

اگر این متغیر پیکربندی را نداشته باشید، مقدار i18n.commitEncoding به جای آن استفاده می‌شود.

توجه داشته باشید که ما عمداً تصمیم گرفتیم هنگام ایجاد یک کامیت، پیام لاگ کامیت را برای تحمیل UTF-8 در سطح شیء کامیت دوباره کدگذاری نکنیم، زیرا بازکدگذاری به UTF-8 لزوماً یک عملیات برگشت‌پذیر نیست.

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

2026-06-29 Git 2.55.0