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

git-log - نمایش لاگ‌های کامیت

git log [<options>] [<revision-range>] [[--] <path>...]

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

کامیت‌هایی را فهرست می‌کند که با دنبال کردن پیوندهای والد (parent) از کامیت(های) داده‌شده قابل دسترسی هستند، اما کامیت‌هایی را که از موارد دارای علامت ^ در ابتدای آن‌ها قابل دسترسی باشند مستثنی می‌کند. خروجی به‌طور پیش‌فرض به ترتیب معکوس زمانی ارائه می‌شود.

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

بنابراین، دستور زیر:

$ git log foo bar ^baz

به این معنی است: «فهرست کردن تمام کامیت‌هایی که از foo یا bar قابل دسترسی هستند، اما از baz قابل دسترسی نیستند».

علامت‌گذاری ویژه "<commit1>..<commit2>" را می‌توان به‌عنوان شکل کوتاه‌شده "^<commit1> <commit2>" به کار برد. برای نمونه، هر یک از موارد زیر را می‌توان به‌جای یکدیگر استفاده کرد:

$ git log origin..HEAD
$ git log HEAD ^origin

علامت‌گذاری ویژه دیگر "<commit1>...<commit2>" است که برای ادغام‌ها سودمند است. مجموعه کامیت‌های حاصل، تفاضل متقارن بین دو عملوند است. دو دستور زیر معادل یکدیگر هستند:

$ git log A B --not $(git merge-base --all A B)
$ git log A...B

این دستور گزینه‌های مربوط به دستور git-rev-list(1) را برای کنترل اینکه چه چیزی و چگونه نمایش داده شود، و گزینه‌های مربوط به دستور git-diff(1) را برای کنترل نحوه نمایش تغییراتی که هر کامیت اعمال می‌کند، می‌پذیرد.

--follow

فهرست کردن تاریخچه یک فایل را فراتر از تغییر نام‌ها ادامه می‌دهد (فقط برای یک فایل کار می‌کند).

--no-decorate, --decorate[=(short|full|auto|no)]

نام‌های ارجاع (ref) هر کامیت نمایش‌داده‌شده را چاپ می‌کند. مقادیر ممکن عبارتند از:

short

پیشوندهای نام ارجاع refs/heads/, refs/tags/ و refs/remotes/ چاپ نمی‌شوند.

full

نام کامل ارجاع (شامل پیشوند) چاپ می‌شود.

auto

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

گزینه --decorate حالت کوتاه‌نویسی برای --decorate=short است. در صورت پیکربندی، به‌طور پیش‌فرض از مقدار پیکربندی log.decorate استفاده می‌کند، در غیر این صورت مقدار auto به کار می‌رود.

--decorate-refs=<pattern>, --decorate-refs-exclude=<pattern>

برای هر ارجاع کاندید، اگر با هر یک از پارامترهای <pattern> داده‌شده به --decorate-refs-exclude مطابقت داشته باشد یا اگر با هیچ‌یک از پارامترهای <pattern> داده‌شده به --decorate-refs تطبیق نداشته باشد، از آن برای نشانه‌گذاری (تزیین) استفاده نمی‌شود. گزینه پیکربندی log.excludeDecoration امکان استثنا کردن ارجاع‌ها از نشانه‌گذاری‌ها را فراهم می‌کند، اما یک الگوی صریح در --decorate-refs بر مطابقت موجود در log.excludeDecoration اولویت خواهد داشت.

اگر هیچ‌یک از این گزینه‌ها یا تنظیمات پیکربندی داده نشود، ارجاع‌ها در صورتی به‌عنوان تزیین استفاده می‌شوند که با HEAD, refs/heads/, refs/remotes/, refs/stash/, یا refs/tags/ مطابقت داشته باشند.

--clear-decorations

در صورت مشخص شدن، این گزینه تمام گزینه‌های قبلی --decorate-refs یا --decorate-refs-exclude را پاک می‌کند و فیلتر پیش‌فرض تزیین را آزاد می‌سازد تا شامل همه ارجاع‌ها شود. اگر مقدار پیکربندی log.initialDecorationSet روی all تنظیم شده باشد، این گزینه به‌صورت پیش‌فرض اعمال می‌شود.

--source

نام ارجاع داده‌شده در خط فرمان را که هر کامیت از طریق آن در دسترس قرار گرفته است چاپ می‌کند.

--mailmap, --no-mailmap, --use-mailmap, --no-use-mailmap

از فایل mailmap برای نگاشت نام‌ها و نشانی‌های ایمیل نویسنده و کامیت‌کننده به نام‌های واقعی و نشانی‌های ایمیل استاندارد استفاده می‌کند. به git-shortlog(1) مراجعه کنید.

--full-diff

بدون این پرچم، git log -p <path>... کامیت‌هایی را که مسیرهای مشخص‌شده را تغییر داده‌اند و تفاوت‌های مربوط به همان مسیرهای مشخص‌شده را نشان می‌دهد. با این گزینه، تفاوت کامل برای کامیت‌هایی که مسیرهای مشخص‌شده را لمس کرده‌اند نمایش داده می‌شود؛ این بدان معنی است که "<path>..." فقط کامیت‌ها را محدود می‌کند، و تفاوت را برای آن کامیت‌ها محدود نمی‌سازد.

توجه داشته باشید که این گزینه بر همه انواع خروجی‌های مبتنی بر تفاوت تأثیر می‌گذارد، مانند خروجی‌های تولیدشده توسط --stat و غیره.

--log-size

یک خط log size <number> را در خروجی برای هر کامیت درج می‌کند که در آن <number> طول پیام آن کامیت بر حسب بایت است. هدف آن افزایش سرعت ابزارهایی است که پیام‌های لاگ را از خروجی git log می‌خوانند تا بتوانند فضا را از قبل اختصاص دهند.

-L<start>,<end>:<file>, -L:<funcname>:<file>

سیر تکامل محدوده خطوط مشخص‌شده توسط <start>,<end>, یا با عبارت منظم نام تابع <funcname> را در داخل <file> ردیابی می‌کند. شما نمی‌توانید هیچ محدودکننده مسیر مشخص کنید. این قابلیت در حال حاضر محدود به پیمایشی است که از یک نسخه منفرد شروع می‌شود، یعنی فقط می‌توانید صفر یا یک آرگومان نسخه مثبت مشخص کنید، و <start> و <end> (یا <funcname>) باید در نسخه شروع وجود داشته باشند. می‌توانید این گزینه را بیش از یک بار مشخص کنید. این گزینه مستلزم --patch است. خروجی وصله را می‌توان با استفاده از --no-patch نادیده گرفت. قالب‌های تفاوت غیر از وصله شامل --raw, --name-only, --name-status, و --summary پشتیبانی می‌شوند. قالب‌های آماری تفاوت (--stat, --numstat, --shortstat, --dirstat) در حال حاضر پیاده‌سازی نشده‌اند.

گزینه‌های قالب‌بندی وصله مانند --word-diff, --color-moved, --no-prefix, و گزینه‌های فاصله خالی (-w, -b) پشتیبانی می‌شوند، همچنین گزینه‌های کلنگ (-S, -G) و --diff-filter.

<start> و <end> می‌توانند یکی از این شکل‌ها را داشته باشند:

•<number>

اگر <start> یا <end> یک عدد باشد، شماره خط مطلق را مشخص می‌کند (شمارش خطوط از 1 شروع می‌شود).

•/<regex>/

این شکل از نخستین خط منطبق با عبارت باقاعده POSIX داده‌شده <regex> استفاده می‌کند. اگر <start> یک عبارت باقاعده باشد، از انتهای محدوده قبلی -L (در صورت وجود) جستجو می‌کند، در غیر این صورت از ابتدای فایل جستجو خواهد کرد. اگر <start> به‌صورت ^/<regex>/ باشد، از ابتدای فایل جستجو می‌کند. اگر <end> یک عبارت باقاعده باشد، جستجو را از خط مشخص‌شده با <start> آغاز می‌کند.

•+<offset> یا -<offset>

این حالت فقط برای <end> معتبر است و تعدادی خط قبل یا بعد از خط مشخص‌شده با <start> را تعیین می‌کند.

اگر :<funcname> به‌جای <start> و <end> داده شود، یک عبارت باقاعده است که محدوده را از نخستین خط نام تابع منطبق با <funcname> تا خط نام تابع بعدی مشخص می‌سازد. :<funcname> از انتهای محدوده قبلی -L (در صورت وجود) جستجو می‌کند، در غیر این صورت از ابتدای فایل جستجو خواهد کرد. ^:<funcname> از ابتدای فایل جستجو می‌کند. نام‌های توابع به همان شیوه‌ای تعیین می‌شوند که git diff سرفصل‌های قطعه وصله (patch hunk headers) را محاسبه می‌کند (به Defining a custom hunk-header در gitattributes(5) مراجعه فرمایید).

<revision-range>

تنها کامیت‌های موجود در محدوده بازنگری مشخص‌شده را نشان می‌دهد. هنگامی که هیچ <revision-range> مشخص نشده باشد، به‌طور پیش‌فرض روی HEAD تنظیم می‌شود (یعنی کل تاریخچه منتهی به کامیت کنونی). origin..HEAD تمام کامیت‌های قابل دسترسی از کامیت فعلی (یعنی HEAD) را که از origin قابل دسترسی نیستند مشخص می‌کند. برای فهرست کامل روش‌های نگارش <revision-range>, به بخش Specifying Ranges از gitrevisions(7) مراجعه کنید.

[--] <path>...

تنها کامیت‌هایی را نشان می‌دهد که برای توضیح چگونگی شکل‌گیری فایل‌های منطبق با مسیرهای مشخص‌شده کافی باشند. برای جزئیات و سایر حالت‌های ساده‌سازی به بخش History Simplification در ادامه مراجعه کنید.

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

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

استفاده از گزینه‌های بیشتر عموماً خروجی را بیشتر محدود می‌کند (برای نمونه --since=<date1> نتایج را به کامیت‌های جدیدتر از <date1> محدود می‌سازد، و استفاده از آن همراه با --grep=<pattern> نتایج را به کامیت‌هایی محدود می‌کند که پیام لاگ آن‌ها شامل خطی منطبق با <pattern> باشد)، مگر اینکه خلاف آن ذکر شده باشد.

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

-<number>, -n <number>, --max-count=<number>

خروجی را به نخستین <number> کامیتی که نمایش داده می‌شوند محدود می‌کند.

--max-count-oldest=<number>

خروجی را به آخرین <number> کامیتی که نمایش داده می‌شوند محدود می‌کند.

--skip=<number>

پیش از شروع به نمایش خروجی کامیت‌ها، از <number> کامیت اول صرف‌نظر می‌کند.

--since=<date>, --after=<date>

کامیت‌های جدیدتر از <date> را نمایش می‌دهد. به‌عنوان یک حالت ویژه، today به معنی نیمه‌شب گذشته است.

--since-as-filter=<date>

تمام کامیت‌های جدیدتر از <date> را نمایش می‌دهد. این گزینه به‌جای توقف در نخستین کامیت قدیمی‌تر از <date>, تمام کامیت‌های موجود در محدوده را پیمایش می‌کند.

--until=<date>, --before=<date>

کامیت‌های قدیمی‌تر از <date> را نمایش می‌دهد.

--author=<pattern>, --committer=<pattern>

خروجی کامیت‌ها را به مواردی محدود می‌کند که خطوط هدر نویسنده/ثبت‌کننده آن‌ها با عبارت باقاعده <pattern> مطابقت داشته باشد. با تعیین بیش از یک --author=<pattern>, کامیت‌هایی انتخاب می‌شوند که نویسنده آن‌ها با هر یک از <pattern> ها مطابقت داشته باشد (مشابهاً برای چند مورد --committer=<pattern>).

--grep-reflog=<pattern>

خروجی کامیت‌ها را به مواردی محدود می‌کند که مدخل‌های رِف‌لاگ آن‌ها با عبارت باقاعده <pattern> مطابقت داشته باشد. با تعیین بیش از یک --grep-reflog, کامیت‌هایی انتخاب می‌شوند که پیام رِف‌لاگ آن‌ها با هر یک از الگوهای داده‌شده تطبیق داشته باشد. استفاده از این گزینه بدون به‌کارگیری --walk-reflogs خطا است.

--grep=<pattern>

خروجی کامیت‌ها را به مواردی محدود می‌کند که پیام لاگ آن‌ها با عبارت باقاعده <pattern> مطابقت داشته باشد. با مشخص کردن بیش از یک --grep=<pattern>, کامیت‌هایی انتخاب می‌شوند که پیام آن‌ها با هر یک از <pattern> ها مطابقت کند (اما گزینه --all-match را نیز ببینید).

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

--all-match

خروجی کامیت‌ها را به مواردی محدود می‌کند که با تمام الگوهای داده‌شده به --grep مطابقت داشته باشند، به‌جای مواردی که دست‌کم با یکی تطبیق دارند.

--invert-grep

خروجی کامیت‌ها را به مواردی محدود می‌کند که پیام لاگ آن‌ها با <pattern> مشخص‌شده با --grep=<pattern> مطابقت نداشته باشد.

-i, --regexp-ignore-case

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

--basic-regexp

الگوهای محدودکننده را به‌عنوان عبارات باقاعده پایه (Basic Regular Expressions) در نظر می‌گیرد؛ این رفتار پیش‌فرض است.

-E, --extended-regexp

الگوهای محدودکننده را به‌جای عبارات باقاعده پایه پیش‌فرض، به‌عنوان عبارات باقاعده گسترش‌یافته (Extended Regular Expressions) در نظر می‌گیرد.

-F, --fixed-strings

الگوهای محدودکننده را به‌عنوان رشته‌های ثابت در نظر می‌گیرد (الگو را به‌عنوان یک عبارت باقاعده تفسیر نمی‌کند).

-P, --perl-regexp

الگوهای محدودکننده را به‌عنوان عبارات باقاعده سازگار با پرل (Perl-compatible regular expressions) در نظر می‌گیرد.

پشتیبانی از این نوع عبارات باقاعده یک وابستگی اختیاری در زمان کامپایل است. اگر گیت بدون پشتیبانی از آن‌ها کامپایل شده باشد، ارائه این گزینه باعث خاتمه همراه با خطای برنامه می‌شود.

--remove-empty

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

--merges

تنها کامیت‌های ادغام را چاپ می‌کند. این دقیقاً معادل --min-parents=2 است.

--no-merges

کامیت‌هایی با بیش از یک والد را چاپ نمی‌کند. این دقیقاً معادل --max-parents=1 است.

--min-parents=<number>, --max-parents=<number>, --no-min-parents, --no-max-parents

تنها کامیت‌هایی را نشان می‌دهد که دست‌کم (یا حداکثر) دارای آن تعداد کامیت والد باشند. به‌ویژه، --max-parents=1 مشابه --no-merges, و --min-parents=2 مشابه --merges است. --max-parents=0 تمام کامیت‌های ریشه و --min-parents=3 تمام ادغام‌های اختاپوسی (octopus merges) را نشان می‌دهد.

گزینه‌های --no-min-parents و --no-max-parents این محدودیت‌ها را دوباره (به حالت بدون محدودیت) بازنشانی می‌کنند. شکل‌های معادل عبارتند از --min-parents=0 (هر کامیتی دارای ۰ یا چند والد است) و --max-parents=-1 (اعداد منفی نشان‌دهنده نبود حد بالاست).

--first-parent

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

این گزینه همچنین قالب تفاوت پیش‌فرض برای کامیت‌های ادغام را به first-parent تغییر می‌دهد؛ برای جزئیات به --diff-merges=first-parent مراجعه کنید.

--exclude-first-parent-only

هنگام یافتن کامیت‌ها برای استثنا کردن (با یک ^), به محض دیدن یک کامیت ادغام، تنها نخستین کامیت والد را دنبال می‌کند. این گزینه را می‌توان برای یافتن مجموعه تغییرات در یک شاخه موضوعی از نقطه‌ای که از شاخه دوردست منشعب شده است استفاده کرد، با توجه به این واقعیت که ادغام‌های دلخواه می‌توانند تغییرات معتبری برای شاخه موضوعی باشند.

--maximal-only

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

--not

معنای پیشوند ^ (یا عدم وجود آن) را برای تمام مشخص‌کننده‌های بازنگری بعدی تا گزینه بعدی --not معکوس می‌کند. هنگامی که در خط فرمان قبل از --stdin استفاده شود، بازنگری‌های دریافت‌شده از stdin تحت تأثیر آن قرار نخواهند گرفت. برعکس، هنگامی که از طریق ورودی استاندارد ارسال شود، بازنگری‌های ارسال‌شده در خط فرمان تحت تأثیر آن قرار نخواهند گرفت.

--all

به‌گونه‌ای عمل می‌کند که گویی تمام ارجاع‌های موجود در refs/, به همراه HEAD, در خط فرمان به‌عنوان <commit> فهرست شده‌اند.

--branches[=<pattern>]

به‌گونه‌ای عمل می‌کند که گویی تمام ارجاع‌های موجود در refs/heads در خط فرمان به‌عنوان <commit> فهرست شده‌اند. اگر <pattern> داده شود، شاخه‌ها را به موارد منطبق با الگوی پوسته (shell glob) داده‌شده محدود می‌کند. اگر <pattern> فاقد ?, *, یا [ باشد، وجود /* در انتهای آن به صورت ضمنی فرض می‌شود.

--tags[=<pattern>]

به‌گونه‌ای عمل می‌کند که گویی تمام ارجاع‌های موجود در refs/tags در خط فرمان به‌عنوان <commit> فهرست شده‌اند. اگر <pattern> داده شود، برچسب‌ها را به موارد منطبق با الگوی پوسته داده‌شده محدود می‌کند. اگر الگو فاقد ?, *, یا [ باشد، وجود /* در انتهای آن به صورت ضمنی فرض می‌شود.

--remotes[=<pattern>]

به‌گونه‌ای عمل می‌کند که گویی تمام ارجاع‌های موجود در refs/remotes در خط فرمان به‌عنوان <commit> فهرست شده‌اند. اگر <pattern> داده شود، شاخه‌های ردگیری دوردست را به موارد منطبق با الگوی پوسته داده‌شده محدود می‌کند. اگر الگو فاقد ?, *, یا [ باشد، وجود /* در انتهای آن به صورت ضمنی فرض می‌شود.

--glob=<glob-pattern>

به‌گونه‌ای عمل می‌کند که گویی تمام ارجاع‌های منطبق با الگوی پوسته <glob-pattern> در خط فرمان به‌عنوان <commit> فهرست شده‌اند. پیشوند refs/ در صورت عدم وجود، به‌طور خودکار در ابتدا اضافه می‌شود. اگر الگو فاقد ?, *, یا [ باشد، وجود /* در انتهای آن به صورت ضمنی فرض می‌شود.

--exclude=<glob-pattern>

ارجاع‌های منطبق با <glob-pattern> را که گزینه‌های بعدی --all, --branches, --tags, --remotes, یا --glob در نظر می‌گیرند، شامل نمی‌کند. تکرار این گزینه الگوهای استثنا را تا گزینه بعدی --all, --branches, --tags, --remotes, یا --glob جمع‌آوری می‌کند (سایر گزینه‌ها یا آرگومان‌ها الگوهای جمع‌آوری‌شده را پاک نمی‌کنند).

الگوهای داده‌شده هنگام اعمال روی --branches, --tags, یا --remotes نباید با refs/heads, refs/tags, یا refs/remotes آغاز شوند، و هنگام اعمال روی --glob یا --all باید حتماً با refs/ شروع شوند. اگر یک /* پایانی مد نظر باشد، باید صریحاً قید شود.

--exclude-hidden=(fetch|receive|uploadpack)

ارجاع‌هایی را که توسط git-fetch, git-receive-pack یا git-upload-pack با مراجعه به پیکربندی مناسب fetch.hideRefs, receive.hideRefs یا uploadpack.hideRefs به همراه transfer.hideRefs پنهان می‌شوند، شامل نمی‌کند (به git-config(1) مراجعه کنید). این گزینه بر گزینه شبه‌ارجاع بعدی --all یا --glob تأثیر می‌گذارد و پس از پردازش آن‌ها پاک می‌شود.

--reflog

به‌گونه‌ای عمل می‌کند که گویی تمام اشیای ذکرشده در رِف‌لاگ‌ها در خط فرمان به‌عنوان <commit> فهرست شده‌اند.

--alternate-refs

به‌گونه‌ای عمل می‌کند که گویی تمام اشیای ذکرشده به‌عنوان نوک ارجاع مخازن جایگزین در خط فرمان فهرست شده‌اند. یک مخزن جایگزین هر مخزنی است که دایرکتوری اشیای آن در objects/info/alternates مشخص شده باشد. مجموعه اشیای ارائه‌شده ممکن است توسط core.alternateRefsCommand و غیره اصلاح شود. به git-config(1) مراجعه کنید.

--single-worktree

به‌طور پیش‌فرض، در صورت وجود بیش از یک درخت کاری، تمام درخت‌های کاری توسط گزینه‌های زیر بررسی می‌شوند (به git-worktree(1) مراجعه کنید): --all, --reflog و --indexed-objects. این گزینه آن‌ها را وادار می‌کند تا تنها درخت کاری فعلی را بررسی نمایند.

--ignore-missing

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

--bisect

به‌گونه‌ای عمل می‌کند که گویی ارجاع تنصیف بد refs/bisect/bad در خط فرمان فهرست شده و پس از آن --not و ارجاع‌های تنصیف خوب refs/bisect/good-* آمده است.

--stdin

علاوه بر دریافت آرگومان‌ها از خط فرمان، آن‌ها را از ورودی استاندارد نیز می‌خواند. این گزینه کامیت‌ها و شبه‌گزینه‌هایی مانند --all و --glob= را می‌پذیرد. هنگامی که یک جداکننده -- مشاهده شود، ورودی بعدی به‌عنوان مسیر در نظر گرفته شده و برای محدود کردن نتیجه استفاده می‌شود. پرچم‌هایی مانند --not که از طریق ورودی استاندارد خوانده می‌شوند، تنها برای آرگومان‌هایی که به همان روش ارسال شده‌اند رعایت می‌شوند و بر هیچ‌یک از آرگومان‌های خط فرمان بعدی تأثیر نخواهند گذاشت.

--cherry-mark

مشابه --cherry-pick (در ادامه ببینید) عمل می‌کند اما کامیت‌های معادل را به‌جای حذف کردن، با علامت = و موارد غیرمعادل را با علامت + نشانه‌گذاری می‌نماید.

--cherry-pick

هر کامیتی را که تغییری مشابه کامیت دیگری در «طرف دیگر» ایجاد می‌کند، هنگامی که مجموعه کامیت‌ها با تفاضل متقارن محدود شده باشند، حذف می‌نماید.

برای نمونه، اگر دو شاخه A و B داشته باشید، روش معمول برای فهرست کردن تمام کامیت‌های موجود در یک طرف آن‌ها استفاده از --left-right است (مثال زیر در توضیحات گزینه --left-right را ببینید). با این حال، کامیت‌هایی را که از شاخه دیگر دست‌چین (cherry-pick) شده‌اند نشان می‌دهد (برای مثال «سومین در b» ممکن است از شاخه A دست‌چین شده باشد). با این گزینه، چنین جفت کامیت‌هایی از خروجی مستثنی می‌شوند.

--left-only, --right-only

تنها کامیت‌های سمت مربوطه یک تفاضل متقارن را فهرست می‌کند، یعنی تنها مواردی که با < یا > توسط --left-right علامت‌گذاری می‌شوند.

برای نمونه، --cherry-pick --right-only A...B آن دسته از کامیت‌های موجود در B را که در A هستند یا معادل وصله‌ای با یک کامیت در A می‌باشند حذف می‌کند. به عبارت دیگر، این دستور کامیت‌های + را از git cherry A B فهرست می‌کند. به‌طور دقیق‌تر، --cherry-pick --right-only --no-merges فهرست دقیق را ارائه می‌دهد.

--cherry

مترادفی برای --right-only --cherry-mark --no-merges; سودمند برای محدود کردن خروجی به کامیت‌های سمت خودمان و نشانه‌گذاری مواردی که به سمت دیگر یک تاریخچه شاخه‌بندی‌شده اعمال شده‌اند با دستور git log --cherry upstream...mybranch, مشابه با git cherry upstream mybranch.

-g, --walk-reflogs

به‌جای پیمایش زنجیره نیاکان کامیت، مدخل‌های رِف‌لاگ را از جدیدترین به سمت قدیمی‌ترها پیمایش می‌کند. هنگامی که از این گزینه استفاده می‌شود نمی‌توانید کامیت‌هایی را برای استثنا کردن مشخص کنید (یعنی نمادگذاری‌های ^<commit>, <commit1>..<commit2>, و <commit1>...<commit2> قابل استفاده نیستند).

با قالبی از --pretty به‌جز oneline و reference (به دلایل واضح)، این گزینه باعث می‌شود خروجی دارای دو خط اطلاعات اضافی برگرفته از رِف‌لاگ باشد. نشان‌دهنده رِف‌لاگ در خروجی ممکن است به‌صورت ref@{<Nth>} (که در آن <Nth> اندیس معکوس زمانی در رِف‌لاگ است) یا به‌صورت ref@{<timestamp>} (همراه با <timestamp> آن مدخل) بسته به چند قانون نمایش داده شود:

1.اگر نقطه شروع به‌صورت ref@{<Nth>} مشخص شده باشد، قالب اندیس نمایش داده می‌شود.
2.اگر نقطه شروع به‌صورت ref@{now} مشخص شده باشد، قالب برچسب زمان نمایش داده می‌شود.
3.اگر از هیچ‌کدام استفاده نشده باشد، اما --date در خط فرمان داده شده باشد، برچسب زمان در قالب خواسته‌شده توسط --date نمایش داده می‌شود.
4.در غیر این صورت، قالب اندیس نمایش داده می‌شود.

تحت --pretty=oneline, پیام کامیت با این اطلاعات در همان خط پیشوند می‌گیرد. این گزینه با --reverse قابل ترکیب نیست. همچنین به git-reflog(1) مراجعه کنید.

تحت --pretty=reference, این اطلاعات اصلاً نمایش داده نخواهند شد.

--merge

کامیت‌هایی را که مسیرهای دارای تعارض را در محدوده HEAD...<other> تغییر داده‌اند نمایش می‌دهد، که در آن <other> نخستین شبه‌ارجاع موجود در MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD یا REBASE_HEAD است. تنها زمانی کار می‌کند که ایندکس دارای مدخل‌های ادغام‌نشده باشد. این گزینه را می‌توان برای نمایش کامیت‌های مرتبط هنگام حل تعارض‌های ناشی از یک ادغام ۳-طرفه استفاده کرد.

--boundary

کامیت‌های مرزی مستثنی‌شده را در خروجی می‌آورد. کامیت‌های مرزی با پیشوند - مشخص می‌شوند.

گاهی اوقات شما تنها به بخش‌هایی از تاریخچه علاقه‌مندید، برای نمونه کامیت‌هایی که یک <path> خاص را تغییر می‌دهند. اما ساده‌سازی تاریخچه دو بخش دارد: یک بخش انتخاب کامیت‌ها است و بخش دیگر چگونگی انجام آن، چرا که راهبردهای گوناگونی برای ساده‌سازی تاریخچه وجود دارد.

گزینه‌های زیر کامیت‌های نمایش‌داده‌شده را انتخاب می‌کنند:

<paths>

کامیت‌هایی که <paths> مشخص‌شده را تغییر می‌دهند انتخاب می‌شوند.

--simplify-by-decoration

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

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

گزینه‌های زیر بر نحوه انجام ساده‌سازی تأثیر می‌گذارند:

حالت پیش‌فرض (Default mode)

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

--show-pulls

تمام کامیت‌های حالت پیش‌فرض را شامل می‌شود، به اضافه هر کامیت ادغامی که نسبت به والد نخست TREESAME نباشد ولی نسبت به والد بعدی TREESAME باشد. این حالت برای نمایش کامیت‌های ادغامی که «نخستین بار تغییری را وارد یک شاخه کردند» سودمند است.

--full-history

مشابه حالت پیش‌فرض است، اما بخشی از تاریخچه را هرس نمی‌کند.

--dense

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

--sparse

تمام کامیت‌ها در تاریخچه ساده‌سازی‌شده نمایش داده می‌شوند.

--simplify-merges

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

--ancestry-path[=<commit>]

هنگامی که محدوده‌ای از کامیت‌ها برای نمایش داده می‌شود (مانند <commit1>..<commit2> یا <commit2> ^<commit1>), و یک کامیت <commit> در آن محدوده مشخص گردد، تنها کامیت‌هایی از آن محدوده را نمایش می‌دهد که نیاکان <commit>, نوادگان <commit>, یا خود <commit> باشند. اگر هیچ کامیتی مشخص نشود، از <commit1> (بخش مستثنی‌شده محدوده) به‌عنوان <commit> استفاده می‌کند. می‌توان آن را چندین بار ارسال کرد؛ در این صورت، یک کامیت در صورتی گنجانده می‌شود که هر یک از کامیت‌های ارائه‌شده باشد یا نیا یا نواده یکی از آن‌ها باشد.

توضیحات دقیق‌تر در ادامه می‌آید.

فرض کنید شما foo را به‌عنوان <paths> مشخص کرده‌اید. ما کامیت‌هایی را که foo را تغییر می‌دهند !TREESAME (نایکسان از نظر درخت) و بقیه را TREESAME (یکسان از نظر درخت) می‌نامیم. (در یک diff فیلترشده برای foo، آن‌ها به ترتیب متفاوت و برابر به نظر می‌رسند.)

در ادامه، ما همواره به همین تاریخچه نمونه برای نشان دادن تفاوت‌های بین تنظیمات ساده‌سازی ارجاع خواهیم داد. فرض می‌کنیم شما در حال فیلتر کردن برای فایل foo در این گراف کامیت هستید:

  .-A---M---N---O---P---Q
 /     /   /   /   /   /
I     B   C   D   E   Y
 \   /   /   /   /   /
  `-------------'   X

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

•I کامیت اولیه است که در آن foo با محتوای asdf و فایلی به نام quux با محتوای quux وجود دارد. کامیت‌های اولیه با یک درخت خالی مقایسه می‌شوند، بنابراین I مقدار !TREESAME دارد.
•در A, فایل foo تنها حاوی foo است.
•B شامل همان تغییر A است. ادغام آن M بدیهی (trivial) است و بنابراین نسبت به تمام والدین TREESAME است.
•C تغییری در foo ایجاد نمی‌کند، اما ادغام آن N آن را به foobar تغییر می‌دهد، بنابراین نسبت به هیچ والدی TREESAME نیست.
•D مقدار foo را روی baz تنظیم می‌کند. ادغام آن O رشته‌های برگرفته از N و D را به foobarbaz ترکیب می‌کند؛ یعنی نسبت به هیچ والدی TREESAME نیست.
•E مقدار quux را به xyzzy تغییر می‌دهد، و ادغام آن P رشته‌ها را به quux xyzzy ترکیب می‌نماید. P نسبت به O دارای وضعیت TREESAME است، اما نسبت به E نیست.
•X یک کامیت ریشه مستقل است که فایل جدید side را اضافه کرده، و Y آن را اصلاح نموده است. Y نسبت به X وضعیت TREESAME دارد. ادغام آن Q فایل side را به P اضافه کرده است، و Q نسبت به P دارای وضعیت TREESAME است، اما نسبت به Y نیست.

دستور rev-list در تاریخچه به سمت عقب پیمایش می‌کند، و بر اساس اینکه آیا --full-history و/یا بازنویسی والدین (از طریق --parents یا --children) استفاده شده باشد، کامیت‌ها را شامل یا مستثنی می‌سازد. تنظیمات زیر در دسترس هستند.

حالت پیش‌فرض (Default mode)

کامیت‌ها در صورتی که نسبت به هیچ والدی TREESAME نباشند گنجانده می‌شوند (اگرچه این قابل تغییر است، --sparse را در ادامه ببینید). اگر کامیت یک ادغام باشد و نسبت به یک والد TREESAME باشد، تنها همان والد را دنبال می‌کند. (حتی اگر چندین والد TREESAME وجود داشته باشد، فقط یکی از آن‌ها دنبال می‌شود.) در غیر این صورت، تمام والدین دنبال می‌شوند.

این منجر به نتیجه زیر می‌شود:

  .-A---N---O
 /     /   /
I---------D

توجه کنید چگونه قاعده دنبال کردن تنها والد TREESAME (در صورت وجود)، B را کاملاً از بررسی حذف کرد. C از طریق N بررسی شد، اما وضعیت TREESAME داشت. کامیت‌های ریشه با یک درخت خالی مقایسه می‌شوند، بنابراین I دارای وضعیت !TREESAME است.

روابط والد/فرزند تنها با --parents قابل مشاهده هستند، اما این موضوع بر کامیت‌های انتخاب‌شده در حالت پیش‌فرض تأثیری ندارد، بنابراین ما خطوط والدین را نمایش داده‌ایم.

--full-history بدون بازنویسی والدین

این حالت با حالت پیش‌فرض در یک نکته تفاوت دارد: همیشه تمام والدین یک ادغام را دنبال می‌کند، حتی اگر نسبت به یکی از آن‌ها TREESAME باشد. حتی اگر بیش از یک سمت ادغام دارای کامیت‌های گنجانده‌شده باشد، این بدان معنا نیست که خود ادغام نیز شامل شده است! در مثال، به این نتیجه می‌رسیم:
I  A  B  N  D  O  P  Q

M حذف شد زیرا نسبت به هر دو والد وضعیت TREESAME داشت. E, C و B همگی پیمایش شدند، اما تنها B دارای وضعیت !TREESAME بود، بنابراین بقیه ظاهر نمی‌شوند.

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

--full-history با بازنویسی والدین

کامیت‌های عادی تنها در صورتی گنجانده می‌شوند که وضعیت !TREESAME داشته باشند (اگرچه این قابل تغییر است، --sparse را در ادامه ببینید).

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

  .-A---M---N---O---P---Q
 /     /   /   /   /
I     B   /   D   /
 \   /   /   /   /
  `-------------'

با --full-history بدون بازنویسی در بالا مقایسه کنید. توجه داشته باشید که E هرس شد زیرا TREESAME بود، اما فهرست والدین P بازنویسی شد تا شامل والد E یعنی I باشد. همین اتفاق برای C و N, و برای X, Y و Q نیز رخ داد.

علاوه بر تنظیمات فوق، می‌توانید تغییر دهید که آیا وضعیت TREESAME بر گنجاندن تأثیر بگذارد یا خیر:

--dense

کامیت‌های پیمایش‌شده در صورتی گنجانده می‌شوند که نسبت به هیچ والدی TREESAME نباشند.

--sparse

تمام کامیت‌هایی که پیمایش می‌شوند گنجانده خواهند شد.

توجه داشته باشید که بدون --full-history, این گزینه همچنان ادغام‌ها را ساده‌سازی می‌کند: اگر یکی از والدین TREESAME باشد، ما تنها همان یکی را دنبال می‌کنیم، بنابراین سمت‌های دیگر ادغام هرگز پیمایش نمی‌شوند.

--simplify-merges

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

سپس هر کامیت C را به جایگزین آن C' در تاریخچه نهایی بر اساس قوانین زیر ساده می‌کند:

•مقدار C' را روی C تنظیم کنید.
•هر والد P از C' را با نسخه ساده‌شده‌اش P' جایگزین کنید. در این فرایند، والدینی را که نیاکان سایر والدین هستند یا کامیت‌های ریشه‌ای هستند که نسبت به یک درخت خالی وضعیت TREESAME دارند حذف کرده و موارد تکراری را بزدایید، اما دقت کنید که هرگز تمام والدینی را که نسبت به آن‌ها TREESAME هستیم حذف نکنید.
•اگر پس از این بازنویسی والدین، C' یک کامیت ریشه یا ادغام باشد (دارای ۰ یا بیش از ۱ والد باشد)، یک کامیت مرزی باشد، یا !TREESAME باشد، باقی می‌ماند. در غیر این صورت، با تنها والد خود جایگزین می‌شود.

تأثیر این کار به بهترین شکل با مقایسه آن با --full-history همراه با بازنویسی والدین نشان داده می‌شود. مثال به صورت زیر درمی‌آید:

  .-A---M---N---O
 /     /       /
I     B       D
 \   /       /
  `---------'

تفاوت‌های عمده در N, P, و Q را نسبت به --full-history ملاحظه فرمایید:

•از فهرست والدین N's کامیت I حذف شد، زیرا نیاکان والد دیگر یعنی M است. با این وجود، N باقی ماند زیرا وضعیت !TREESAME دارد.
•از فهرست والدین P's نیز مشابهاً I حذف گردید. سپس P به‌طور کامل حذف شد، زیرا یک والد داشت و وضعیت TREESAME داشت.
•فهرست والدین Q's کامیت Y را به X ساده کرد. سپس X حذف شد، چرا که یک ریشه با وضعیت TREESAME بود. Q سپس به‌طور کامل حذف شد، زیرا یک والد داشت و وضعیت TREESAME داشت.

حالت ساده‌سازی دیگری نیز در دسترس است:

--ancestry-path[=<commit>]

کامیت‌های نمایش‌داده‌شده را به مواردی محدود می‌کند که نیاکان <commit>, نوادگان <commit>, یا خود <commit> باشند.

به‌عنوان یک نمونه کاربرد، تاریخچه کامیت زیر را در نظر بگیرید:

    D---E-------F
   /     \       \
  B---C---G---H---I---J
 /                     \
A-------K---------------L--M

یک عبارت معمولی D..M مجموعه کامیت‌هایی را محاسبه می‌کند که نیاکان M هستند، اما مواردی را که نیاکان D می‌باشند مستثنی می‌سازد. این برای مشاهده آنچه برای تاریخچه منتهی به M از زمان D رخ داده مفید است، به این معنی که « M چه چیزی دارد که در D وجود نداشت». نتیجه در این مثال تمام کامیت‌ها خواهد بود، به جز A و B (و البته خود D).

اما هنگامی که بخواهیم بدانیم چه کامیت‌هایی در M به باگ معرفی‌شده توسط D آلوده شده‌اند و نیاز به رفع دارند، ممکن است بخواهیم تنها زیرمجموعه‌ای از D..M را مشاهده کنیم که واقعاً از نوادگان D هستند، یعنی مستثنی کردن C و K. این دقیقاً همان کاری است که گزینه --ancestry-path انجام می‌دهد. اعمال آن روی محدوده D..M به نتیجه زیر می‌انجامد:

E-------F
 \       \
  G---H---I---J
               \
                L--M

ما همچنین می‌توانیم از --ancestry-path=D به‌جای --ancestry-path استفاده کنیم که هنگام اعمال روی محدوده D..M معنای یکسانی دارد اما صریح‌تر است.

اگر در عوض به یک موضوع خاص در این محدوده و تمام کامیت‌های متأثر از آن موضوع علاقه‌مند باشیم، ممکن است تنها بخواهیم زیرمجموعه‌ای از D..M را مشاهده کنیم که آن موضوع را در مسیر نیاکان خود دارند. بنابراین، برای مثال استفاده از --ancestry-path=H D..M به نتیجه زیر می‌انجامد:

  E
   \
C---G---H---I---J
                 \
                  L--M

در حالی که --ancestry-path=K D..M به این نتیجه منجر می‌شود:

K---------------L--M

پیش از بحث درباره گزینه دیگر، یعنی --show-pulls, لازم است یک تاریخچه نمونه جدید بسازیم.

یک مشکل رایج که کاربران هنگام مشاهده تاریخچه ساده‌سازی‌شده با آن مواجه می‌شوند این است که کامیتی که می‌دانند فایلی را تغییر داده است به نوعی در تاریخچه ساده‌شده فایل ظاهر نمی‌شود. بیایید یک مثال جدید را نشان دهیم و بررسی کنیم که گزینه‌هایی مانند --full-history و --simplify-merges در چنین حالتی چگونه کار می‌کنند:

  .-A---M-----C--N---O---P
 /     / \  \  \/   /   /
I     B   \  R-'`-Z'   /
 \   /     \/         /
  \ /      /\        /
   `---X--'  `---Y--'

برای این مثال، فرض کنید I فایل file.txt را ایجاد کرد که توسط A, B, و X به روش‌های متفاوتی اصلاح شد. کامیت‌های تک‌والدی C, Z, و Y تغییری در file.txt ایجاد نمی‌کنند. کامیت ادغام M با حل تعارض ادغام برای گنجاندن هر دو تغییر از A و B ایجاد شد و بنابراین نسبت به هیچ‌کدام TREESAME نیست. اما کامیت ادغام R با نادیده گرفتن محتویات file.txt در M و گرفتن تنها محتویات file.txt در X ایجاد گردید. از این رو، R نسبت به X دارای وضعیت TREESAME است اما نسبت به M نیست. در نهایت، تفکیک طبیعی ادغام برای ایجاد N گرفتن محتویات file.txt در R است، بنابراین N نسبت به R وضعیت TREESAME دارد اما نسبت به C ندارد. کامیت‌های ادغام O و P نسبت به والدین اول خود وضعیت TREESAME دارند، اما به ترتیب نسبت به والدین دوم خود یعنی Z و Y وضعیت TREESAME ندارند.

هنگام استفاده از حالت پیش‌فرض، N و R هر دو دارای یک والد TREESAME هستند، بنابراین آن یال‌ها پیمایش شده و بقیه نادیده گرفته می‌شوند. گراف تاریخچه حاصل به صورت زیر است:

I---X

هنگام استفاده از --full-history, گیت تمام یال‌ها را پیمایش می‌کند. این کار کامیت‌های A و B و ادغام M را آشکار می‌سازد، اما کامیت‌های ادغام O و P را نیز نمایان می‌کند. با بازنویسی والدین، گراف حاصل به شکل زیر خواهد بود:

  .-A---M--------N---O---P
 /     / \  \  \/   /   /
I     B   \  R-'`--'   /
 \   /     \/         /
  \ /      /\        /
   `---X--'  `------'

در اینجا، کامیت‌های ادغام O و P نویز اضافی ایجاد می‌کنند، زیرا در واقع تغییری در file.txt ایجاد نکرده‌اند. آن‌ها تنها موضوعی را ادغام کرده‌اند که بر پایه نسخه قدیمی‌تری از file.txt بنا شده بود. این یک مسئله رایج در مخازنی است که از گردش کاری با مشارکت‌کنندگان موازی زیاد استفاده می‌کنند که شاخه‌های موضوعی خود را در طول یک تنه اصلی ادغام می‌نمایند: ادغام‌های نامرتبط زیادی در نتایج --full-history ظاهر می‌شوند.

هنگام استفاده از گزینه --simplify-merges, کامیت‌های O و P از نتایج ناپدید می‌شوند. دلیل آن این است که والدین دوم بازنویسی‌شده O و P از والدین اول آن‌ها قابل دسترسی هستند. آن یال‌ها حذف می‌شوند و سپس کامیت‌ها مانند کامیت‌های تک‌والدی به نظر می‌رسند که نسبت به والد خود TREESAME هستند. این اتفاق برای کامیت N نیز رخ می‌دهد و نمایی از تاریخچه به صورت زیر ایجاد می‌کند:

  .-A---M--.
 /     /    \
I     B      R
 \   /      /
  \ /      /
   `---X--'

در این نما، ما تمام تغییرات تک‌والدی مهم از A, B, و X را می‌بینیم. همچنین ادغام با دقت حل‌شده M و ادغام نه‌چندان با دقت حل‌شده R را مشاهده می‌کنیم. این معمولاً اطلاعات کافی برای تعیین اینکه چرا کامیت‌های A و B در نمای پیش‌فرض از تاریخچه «ناپدید شدند» را فراهم می‌سازد. با این حال، چند مشکل در این رویکرد وجود دارد.

مشکل نخست کارایی است. برخلاف هر گزینه قبلی، گزینه --simplify-merges مستلزم پیمایش کل تاریخچه کامیت پیش از بازگرداندن حتی یک نتیجه است. این می‌تواند استفاده از این گزینه را برای مخازن بسیار بزرگ دشوار سازد.

مشکل دوم موضوع حسابرسی (auditing) است. هنگامی که مشارکت‌کنندگان زیادی روی یک مخزن کار می‌کنند، مهم است که کدام کامیت‌های ادغام تغییری را وارد یک شاخه مهم کرده‌اند. ادغام مشکل‌ساز R در بالا احتمالاً آن کامیت ادغامی نبوده است که برای ادغام در یک شاخه مهم استفاده شده است. در عوض، ادغام N برای ادغام R و X در شاخه مهم به کار رفته است. این کامیت ممکن است اطلاعاتی درباره اینکه چرا تغییر X جایگزین تغییرات A و B شد در پیام کامیت خود داشته باشد.

--show-pulls

علاوه بر کامیت‌های نمایش‌داده‌شده در تاریخچه پیش‌فرض، هر کامیت ادغامی را که نسبت به والد نخست خود TREESAME نیست اما نسبت به والد بعدی TREESAME است نمایش می‌دهد.

هنگامی که یک کامیت ادغام توسط --show-pulls گنجانده می‌شود، با ادغام به‌گونه‌ای رفتار می‌شود که گویی تغییر را از شاخه دیگری «کشیده» (pull) است. هنگام استفاده از --show-pulls در این مثال (و بدون گزینه‌های دیگر) گراف حاصل عبارت است از:

I---X---R---N

در اینجا، کامیت‌های ادغام R و N گنجانده شده‌اند زیرا آن‌ها به ترتیب کامیت‌های X و R را به شاخه پایه وارد کردند. این ادغام‌ها دلیلی هستند که کامیت‌های A و B در تاریخچه پیش‌فرض ظاهر نمی‌شوند.

هنگامی که --show-pulls همراه با --simplify-merges استفاده شود، گراف شامل تمام اطلاعات لازم خواهد بود:

  .-A---M--.   N
 /     /    \ /
I     B      R
 \   /      /
  \ /      /
   `---X--'

توجه داشته باشید از آنجا که M از R قابل دسترسی است، یال از N به M با ساده‌سازی حذف شد. با این حال، N همچنان به‌عنوان یک کامیت مهم در تاریخچه ظاهر می‌شود زیرا تغییر R را به شاخه اصلی «کشیده» است.

گزینه --simplify-by-decoration به شما امکان می‌دهد تنها نمای کلی از توپولوژی تاریخچه را با حذف کامیت‌هایی که توسط برچسب‌ها ارجاع داده نشده‌اند مشاهده کنید. کامیت‌ها در صورتی به‌عنوان !TREESAME علامت‌گذاری می‌شوند (به عبارت دیگر، پس از قوانین ساده‌سازی تاریخچه توضیح داده‌شده در بالا حفظ می‌شوند) که (۱) توسط برچسب‌ها ارجاع داده شده باشند، یا (۲) محتویات مسیرهای داده‌شده در خط فرمان را تغییر دهند. تمام کامیت‌های دیگر به‌عنوان TREESAME علامت‌گذاری می‌شوند (مشمول حذف از طریق ساده‌سازی).

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

--date-order

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

--author-date-order

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

--topo-order

هیچ والدی را پیش از نمایش تمام فرزندانش نشان نمی‌دهد، و از نمایش درهم‌آمیخته کامیت‌ها در خطوط تاریخچه چندگانه جلوگیری می‌کند.

برای نمونه، در یک تاریخچه کامیت مانند این:

---1----2----4----7
    \              \
     3----5----6----8---

که در آن اعداد نشان‌دهنده ترتیب برچسب‌های زمان کامیت هستند، دستور git rev-list و دستورات مشابه همراه با --date-order کامیت‌ها را به ترتیب برچسب زمان نمایش می‌دهند: 8 7 6 5 4 3 2 1.

با --topo-order, آن‌ها به صورت 8 6 5 3 7 4 2 1 (یا 8 7 4 2 6 5 3 1) نمایش داده می‌شوند؛ برخی از کامیت‌های قدیمی‌تر قبل از کامیت‌های جدیدتر نشان داده می‌شوند تا از مخلوط شدن کامیت‌های دو مسیر توسعه موازی جلوگیری شود.

--reverse

کامیت‌های انتخاب‌شده برای نمایش را (به بخش Commit Limiting در بالا مراجعه کنید) به ترتیب معکوس خروجی می‌دهد. با --walk-reflogs قابل ترکیب نیست.

این گزینه‌ها بیشتر برای بسته‌بندی مخازن گیت هدف‌گذاری شده‌اند.

--no-walk[=(sorted|unsorted)]

تنها کامیت‌های ارائه‌شده را نشان می‌دهد، اما نیاکان آن‌ها را پیمایش نمی‌کند. اگر محدوده‌ای مشخص شده باشد، این گزینه هیچ تأثیری ندارد. اگر آرگومان unsorted داده شود، کامیت‌ها به ترتیبی که در خط فرمان وارد شده‌اند نمایش می‌یابند. در غیر این صورت (اگر sorted یا هیچ آرگومانی داده نشده باشد)، کامیت‌ها به ترتیب معکوس زمانی بر اساس زمان کامیت نمایش داده می‌شوند. با --graph قابل ترکیب نیست.

--do-walk

گزینه قبلی --no-walk را لغو می‌کند.

--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 بررسی کرده و خروجی را نمایش می‌دهد.

--relative-date

مترادفی برای --date=relative است.

--date=<format>

تنها برای تاریخ‌هایی که در قالب انسان‌خوان نمایش داده می‌شوند اعمال می‌شود، مانند زمانی که از --pretty استفاده می‌شود. متغیر پیکربندی log.date یک مقدار پیش‌فرض را برای گزینه --date دستور log تعیین می‌کند. به‌طور پیش‌فرض، تاریخ‌ها در منطقه زمانی اصلی (یا کامیت‌کننده یا نویسنده) نمایش داده می‌شوند. اگر -local به انتهای قالب اضافه شود (برای نمونه، iso-local), منطقه زمانی محلی کاربر به‌جای آن استفاده می‌شود.

--date=relative تاریخ‌ها را نسبت به زمان فعلی نشان می‌دهد، مانند «۲ ساعت پیش». گزینه -local هیچ تأثیری بر --date=relative ندارد.

--date=local یک نام مستعار برای --date=default-local است.

--date=iso (یا --date=iso8601) برچسب‌های زمان را در قالبی شبیه به ISO 8601 نمایش می‌دهد. تفاوت‌ها با قالب سخت‌گیرانه ISO 8601 عبارتند از:

•یک فاصله به‌جای جداکننده تاریخ/زمان T
•یک فاصله بین زمان و منطقه زمانی
•عدم وجود دو نقطه بین ساعت و دقیقه منطقه زمانی

--date=iso-strict (یا --date=iso8601-strict) برچسب‌های زمان را در قالب دقیق و سخت‌گیرانه ISO 8601 نمایش می‌دهد.

--date=rfc (یا --date=rfc2822) برچسب‌های زمان را در قالب RFC 2822 نشان می‌دهد که اغلب در پیام‌های ایمیل یافت می‌شود.

--date=short تنها تاریخ را بدون زمان، در قالب YYYY-MM-DD نمایش می‌دهد.

--date=raw تاریخ را به‌صورت ثانیه‌های سپری‌شده از مبدأ یونیکس (1970-01-01 00:00:00 UTC) و به دنبال آن یک فاصله، و سپس منطقه زمانی را به‌عنوان یک آفست از UTC (یک + یا - همراه با چهار رقم؛ دو رقم اول ساعت و دو رقم دوم دقیقه) نشان می‌دهد. یعنی به‌گونه‌ای که گویی برچسب زمان با strftime("%s %z") قالب‌بندی شده است. توجه داشته باشید که گزینه -local بر مقدار ثانیه‌های مبدأ (که همیشه بر حسب UTC سنجیده می‌شود) تأثیری ندارد، اما مقدار منطقه زمانی همراه آن را تغییر می‌دهد.

--date=human اگر منطقه زمانی با منطقه زمانی فعلی مطابقت نداشته باشد آن را نمایش می‌دهد، و اگر مطابقت داشته باشد کل تاریخ را چاپ نمی‌کند (یعنی از چاپ سال برای تاریخ‌های «امسال» صرف‌نظر می‌کند، و همچنین کل تاریخ را در صورتی که مربوط به چند روز گذشته باشد حذف کرده و صرفاً روز هفته را بیان می‌کند). برای تاریخ‌های قدیمی‌تر، ساعت و دقیقه نیز حذف می‌شوند.

--date=unix تاریخ را به‌عنوان برچسب زمان مبدأ یونیکس (ثانیه‌ها از سال ۱۹۷۰) نشان می‌دهد. همانند --raw, این مقدار همیشه بر حسب UTC است و بنابراین -local هیچ تأثیری ندارد.

--date=format:<format> مقدار <format> را به تابع strftime سیستم شما ارسال می‌کند، به استثنای %s, %z, و %Z که به‌صورت داخلی مدیریت می‌شوند. از --date=format:%c برای نمایش تاریخ در قالب ترجیحی زبان/محیط (locale) سیستم خود استفاده کنید. برای فهرست کامل جانگهدارنده‌های قالب به راهنمای strftime(3) مراجعه فرمایید. هنگام استفاده از -local, نحو صحیح به‌صورت --date=format-local:<format> است.

--date=default قالب پیش‌فرض است و بر اساس خروجی ctime(3) عمل می‌کند. این گزینه یک خط منفرد شامل سه حرف روز هفته، سه حرف نام ماه، روز ماه، ساعت-دقیقه-ثانیه در قالب "HH:MM:SS" و به دنبال آن سال ۴ رقمی، به اضافه اطلاعات منطقه زمانی را نشان می‌دهد، مگر اینکه از منطقه زمانی محلی استفاده شده باشد؛ برای نمونه: Thu Jan 1 00:00:00 1970 +0000.

--parents

والدین کامیت را نیز چاپ می‌کند (به فرم "commit parent..."). همچنین بازنویسی والدین را فعال می‌سازد، به بخش History Simplification در بالا مراجعه کنید.

--children

فرزندان کامیت را نیز چاپ می‌کند (به فرم "commit child..."). همچنین بازنویسی والدین را فعال می‌سازد، به بخش History Simplification در بالا مراجعه کنید.

--left-right

مشخص می‌کند که یک کامیت از کدام سمت تفاضل متقارن قابل دسترسی است. کامیت‌های سمت چپ با پیشوند < و کامیت‌های سمت راست با > علامت‌گذاری می‌شوند. اگر با --boundary ترکیب شود، آن کامیت‌ها با پیشوند - مشخص می‌گردند.

برای نمونه، اگر چنین توپولوژی داشته باشید:

    y---b---b  branch B
   / \ /
  /   .
 /   / \
o---x---a---a  branch A

خروجی شبیه به این دریافت خواهید کرد:

$ git rev-list --left-right --boundary --pretty=oneline A...B
>bbbbbbb... 3rd on b
>bbbbbbb... 2nd on b
<aaaaaaa... 3rd on a
<aaaaaaa... 2nd on a
-yyyyyyy... 1st on b
-xxxxxxx... 1st on a

--graph

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

این گزینه بازنویسی والدین را فعال می‌کند؛ به بخش History Simplification در بالا مراجعه کنید.

این گزینه به‌طور پیش‌فرض متضمن گزینه --topo-order است، اما گزینه --date-order را نیز می‌توان مشخص کرد.

--show-linear-break[=<barrier>]

هنگامی که از --graph استفاده نمی‌شود، تمام شاخه‌های تاریخچه مسطح (flatten) می‌شوند که می‌تواند تشخیص اینکه دو کامیت متوالی متعلق به یک شاخه خطی نیستند را دشوار سازد. این گزینه در چنین حالتی یک مانع (barrier) میان آن‌ها قرار می‌دهد. اگر <barrier> مشخص شده باشد، این رشته به‌جای رشته پیش‌فرض نمایش داده می‌شود.

--graph-lane-limit=<n>

هنگامی که از --graph استفاده می‌شود، تعداد خطوط (lanes) گراف را برای نمایش محدود می‌کند. خطوط بیش از حد مجاز با علامت کوتاه‌سازی ~ جایگزین می‌شوند. به‌طور پیش‌فرض روی 0 (بدون محدودیت) تنظیم شده است؛ مقادیر صفر و منفی نادیده گرفته شده و به‌عنوان بدون محدودیت در نظر گرفته می‌شوند.

اگر کامیت یک ادغام باشد و چنانچه قالب سفارشی یکی از موارد 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) تأثیری ندارد. برای دریافت نام‌های کامل اشیاء در قالب تفاوت خام، از --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

به‌طور پیش‌فرض، git log هیچ خروجی تفاوتی (diff) تولید نمی‌کند. گزینه‌های زیر را می‌توان برای نمایش تغییرات ایجادشده توسط هر کامیت استفاده کرد.

توجه داشته باشید مگر اینکه یکی از متغیرهای --diff-merges (شامل گزینه‌های کوتاه -m, -c, --cc, و --dd) صراحتاً مشخص شده باشد، کامیت‌های ادغام خروجی تفاوت را نشان نخواهند داد، حتی اگر یک قالب تفاوت مانند --patch انتخاب شده باشد، و همچنین با گزینه‌های جستجو مانند -S مطابقت نخواهند داشت. استثنا زمانی است که --first-parent استفاده شود، که در این صورت first-parent قالب پیش‌فرض برای کامیت‌های ادغام است.

-p, -u, --patch

تولید وصله (به بخش «تولید متن وصله با P-» مراجعه کنید).

-s, --no-patch

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

-m

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

-c

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

--cc

تولید خروجی تفاوت ترکیبی فشرده برای کامیت‌های ادغام. میان‌بری برای --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>

مشخص کردن قالب تفاوتی که باید برای کامیت‌های ادغام استفاده شود. مقدار پیش‌فرض f است، مگر اینکه --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

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

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

--combined-all-paths

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

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

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

--output=<file>

خروجی را به‌جای stdout در یک فایل خاص ذخیره می‌کند.

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

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

--raw

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

--patch-with-raw

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

-t

اشیای درخت (tree objects) را در خروجی diff نشان می‌دهد.

--indent-heuristic

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

--no-indent-heuristic

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

--minimal

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

--patience

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

--histogram

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

--anchored=<text>

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

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

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

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

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

default, myers

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

minimal

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

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 بر تمام دستوراتی که نمودار stat تولید می‌کنند تأثیر می‌گذارد، در حالی که تنظیم 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) و تغییرات حالت (mode) (به ترتیب +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, مجموع درصدهای گزارش‌شده ممکن است از ۱۰۰٪ فراتر رود. رفتار پیش‌فرض (غیرتجمعی) را می‌توان با پارامتر 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>]

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

--no-color

خاموش کردن تفاوت رنگی. مشابه --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>

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

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

+    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> تعیین می‌شود. تمام فایل‌هایی که نام مسیر آن‌ها با الگوی نخست مطابقت دارد ابتدا خروجی داده می‌شوند، سپس تمام فایل‌های منطبق با الگوی دوم (اما نه اولی) خروجی داده می‌شوند و به همین ترتیب. تمام فایل‌هایی که با هیچ الگویی مطابقت ندارند در پایان خروجی داده می‌شوند، به‌گونه‌ای که گویی یک الگوی ضمنی match-all در انتهای فایل وجود داشته است. اگر چند نام مسیر رتبه یکسانی داشته باشند (با همان الگو مطابقت داشته باشند اما با الگوهای قبلی تطابق نداشته باشند)، ترتیب خروجی آن‌ها نسبت به یکدیگر همان ترتیب عادی خواهد بود.

فایل <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

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

--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>

نمایش زمینه (context) میان قطعات (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) یا دستورات زیرساختی 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 به معنی نبود محدودیت است. با نویسه‌های عام (wildcards) در الگوی مسیر قابل ترکیب نیست. با فرض یک درخت حاوی 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

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

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

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

اجرای دستورات git-diff(1), git-log(1), git-show(1), git-diff-index(1), git-diff-tree(1), یا git-diff-files(1) همراه با گزینه -p متن وصله (patch text) تولید می‌کند. می‌توانید ایجاد متن وصله را از طریق متغیرهای محیطی 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/ نیستند.

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

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

3.نام مسیرهای دارای نویسه‌های «نامعمول» مطابق توضیحات متغیر پیکربندی core.quotePath در داخل گیومه قرار می‌گیرند (به git-config(1) مراجعه کنید).
4.تمام فایل‌های file1 در خروجی به فایل‌های قبل از کامیت ارجاع دارند، و تمام فایل‌های file2 به فایل‌های بعد از کامیت اشاره می‌کنند. اعمال متوالی هر تغییر روی هر فایل نادرست است. برای نمونه، این وصله a و b را تعویض می‌کند:
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) مراجعه نمایید.

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

قالب "combined diff" به صورت زیر است:

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> @@@

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

برخلاف قالب سنتی diff یکپارچه (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 log --no-merges

نمایش کل تاریخچه کامیت، با نادیده گرفتن تمام ادغام‌ها

git log v2.6.12.. include/scsi drivers/scsi

نمایش تمام کامیت‌ها از نسخه v2.6.12 که فایلی را در زیردایرکتوری‌های include/scsi یا drivers/scsi تغییر داده‌اند

git log --since="2 weeks ago" -- gitk

نمایش تغییرات طی دو هفته گذشته برای فایل gitk. استفاده از -- برای جلوگیری از اشتباه گرفتن با شاخه به نام gitk ضروری است.

git log --name-status release..test

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

git log --follow builtin/rev-list.c

نمایش کامیت‌هایی که builtin/rev-list.c را تغییر داده‌اند، شامل کامیت‌هایی که پیش از اختصاص نام فعلی به فایل رخ داده‌اند.

git log --branches --not --remotes=origin

نمایش تمام کامیت‌هایی که در هر یک از شاخه‌های محلی وجود دارند اما در هیچ‌یک از شاخه‌های ردگیری دوردست برای origin نیستند (آنچه شما دارید و origin فاقد آن است).

git log master --not --remotes=*/master

نمایش تمام کامیت‌هایی که در master محلی هستند اما در هیچ‌یک از شاخه‌های master مخزن دوردست قرار ندارند.

git log -p -m --first-parent

نمایش تاریخچه شامل diff تغییرات، اما تنها از دیدگاه «شاخه اصلی»، با صرف‌نظر از کامیت‌های برگرفته از شاخه‌های ادغام‌شده، و نمایش تفاوت‌های کامل تغییرات ایجادشده توسط ادغام‌ها. این تنها زمانی منطقی است که از سیاست سخت‌گیرانه‌ای برای ادغام تمام شاخه‌های موضوعی هنگام باقی ماندن روی یک شاخه یکپارچه‌سازی واحد پیروی شود.

git log -L '/int main/',/^}/:main.c

نمایش چگونگی تکامل تابع main() در فایل main.c در طول زمان.

git log -3

تعداد کامیت‌های قابل نمایش را به ۳ محدود می‌کند.

گیت تا حدودی نسبت به کدگذاری نویسه‌ها خنثی (agnostic) عمل می‌کند.

•محتوای اشیای blob توالی‌های تفسیرنشده‌ای از بایت‌ها هستند. هیچ تبدیل کدگذاری در سطح هسته گیت وجود ندارد.
•نام مسیرها در فرم نرمال‌سازی C یونیکد (UTF-8) کدگذاری می‌شوند. این موضوع در مورد اشیای درخت، فایل ایندکس، نام‌های ارجاع، و همچنین نام مسیرها در آرگومان‌های خط فرمان، متغیرهای محیطی و فایل‌های پیکربندی (.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 کدگذاری شوند، هم هسته و هم ابزارهای سطح بالای گیت (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 بازکدگذاری کنند، مگر اینکه خلاف آن مشخص شده باشد. می‌توانید کدگذاری خروجی مورد نظر را با i18n.logOutputEncoding در فایل .git/config مشخص نمایید، به این شکل:
[i18n]
        logOutputEncoding = ISO-8859-1

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

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

برای متغیرهای هسته به git-config(1) و برای تنظیمات مربوط به تولید تفاوت به git-diff(1) مراجعه فرمایید.

format.pretty

مقدار پیش‌فرض برای گزینه --format. (به Pretty Formats در بالا مراجعه کنید.) پیش‌فرض medium است.

i18n.logOutputEncoding

کدگذاری مورد استفاده هنگام نمایش لاگ‌ها. (به Discussion در بالا مراجعه کنید.) در صورت تنظیم، به‌طور پیش‌فرض مقدار i18n.commitEncoding و در غیر این صورت UTF-8 است.

تمام موارد بالای این خط در این بخش از مستندات git-config(1) درج نشده‌اند. محتوایی که در ادامه می‌آید همان مواردی است که در آنجا یافت می‌شود:

log.abbrevCommit

اگر true باشد، باعث می‌شود git-log(1), git-show(1), و git-whatchanged(1) گزینه --abbrev-commit را فرض کنند. می‌توانید این گزینه را با --no-abbrev-commit لغو کنید.

log.date

تنظیم حالت پیش‌فرض تاریخ-زمان برای دستور log. تنظیم یک مقدار برای log.date مشابه استفاده از گزینه --date دستور git log است. برای جزئیات به git-log(1) مراجعه فرمایید.

اگر قالب روی "auto:foo" تنظیم شده باشد و صفحه‌بندی (pager) در حال استفاده باشد، قالب "foo" برای قالب تاریخ استفاده خواهد شد. در غیر این صورت، از "default" استفاده می‌شود.

log.decorate

چاپ نام‌های ارجاع هر کامیت نمایش‌داده‌شده توسط دستور log. مقادیر ممکن عبارتند از:

short

پیشوندهای نام ارجاع refs/heads/, refs/tags/ و refs/remotes/ چاپ نمی‌شوند.

full

نام کامل ارجاع (شامل پیشوند) چاپ می‌شود.

auto

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

این معادل گزینه --decorate از git log است.

log.initialDecorationSet

به‌طور پیش‌فرض، git log تنها تزیینات را برای فضاهای نام ارجاع شناخته‌شده خاصی نشان می‌دهد. اگر all مشخص شود، تمام ارجاع‌ها به‌عنوان تزیینات نشان داده می‌شوند.

log.excludeDecoration

استثنا کردن الگوهای مشخص‌شده از تزیینات لاگ. این مشابه گزینه خط فرمان --decorate-refs-exclude است، اما گزینه پیکربندی را می‌توان با گزینه --decorate-refs بازنویسی کرد.

log.diffMerges

تنظیم قالب تفاوتی که باید هنگام مشخص شدن --diff-merges=on استفاده شود؛ برای جزئیات به --diff-merges در git-log(1) مراجعه کنید. پیش‌فرض separate است.

log.follow

اگر true باشد، git log هنگامی که یک <path> منفرد داده شود، به‌گونه‌ای عمل می‌کند که گویی گزینه --follow استفاده شده است. این گزینه همان محدودیت‌های --follow را دارد، یعنی نمی‌توان از آن برای دنبال کردن چند فایل استفاده کرد و روی تاریخچه‌های غیرخطی عملکرد خوبی ندارد.

log.graphColors

فهرستی از رنگ‌ها، جداشده با کاما، که می‌توان از آن‌ها برای ترسیم خطوط تاریخچه در git log --graph استفاده کرد.

log.showRoot

اگر true باشد، کامیت اولیه به‌صورت یک رویداد بزرگ ایجاد نشان داده می‌شود. این معادل یک diff در برابر یک درخت خالی است. ابزارهایی مانند git-log(1) یا git-whatchanged(1) که معمولاً کامیت ریشه را پنهان می‌کنند، اکنون آن را نشان خواهند داد. به‌طور پیش‌فرض true است.

log.showSignature

اگر true باشد، باعث می‌شود git-log(1), git-show(1), و git-whatchanged(1) گزینه --show-signature را فرض کنند.

log.mailmap

اگر true باشد، باعث می‌شود git-log(1), git-show(1), و git-whatchanged(1) گزینه --use-mailmap را فرض کنند، در غیر این صورت --no-use-mailmap فرض می‌شود. به‌طور پیش‌فرض true است.

notes.mergeStrategy

کدام راهبرد ادغام به‌طور پیش‌فرض هنگام حل تعارض‌های یادداشت‌ها انتخاب شود. باید یکی از موارد manual, ours, theirs, union, یا cat_sort_uniq باشد. پیش‌فرض manual است. برای اطلاعات بیشتر درباره هر راهبرد به بخش "NOTES MERGE STRATEGIES" از git-notes(1) مراجعه کنید.

این تنظیم را می‌توان با ارسال گزینه --strategy به git-notes(1) بازنویسی کرد.

notes.<name>.mergeStrategy

کدام راهبرد ادغام هنگام انجام ادغام یادداشت‌ها در refs/notes/<name> انتخاب شود. این گزینه بر متغیر کلی‌تر notes.mergeStrategy اولویت دارد. برای اطلاعات بیشتر درباره راهبردهای موجود به بخش "NOTES MERGE STRATEGIES" در git-notes(1) مراجعه کنید.

notes.displayRef

کدام ارجاع (یا ارجاع‌ها، در صورت استفاده از glob یا تعیین بیش از یک بار)، علاوه بر مجموعه پیش‌فرض تعیین‌شده توسط core.notesRef یا GIT_NOTES_REF, برای خواندن یادداشت‌ها هنگام نمایش پیام‌های کامیت با خانواده دستورات git log استفاده شود.

این تنظیم را می‌توان با متغیر محیطی GIT_NOTES_DISPLAY_REF که باید فهرستی از ارجاع‌ها یا globهای جداشده با دو نقطه باشد بازنویسی کرد.

برای ارجاع‌هایی که وجود ندارند هشداری صادر می‌شود، اما الگوی glob که با هیچ ارجاعی تطابق نداشته باشد بدون هشدار نادیده گرفته می‌شود.

این تنظیم را می‌توان با گزینه --no-notes برای خانواده دستورات git-log(1) یا با گزینه --notes=<ref> پذیرفته‌شده توسط آن دستورات غیرفعال کرد.

مقدار مؤثر core.notesRef (که احتمالاً توسط GIT_NOTES_REF بازنویسی شده است) نیز به‌طور ضمنی به فهرست ارجاع‌های نمایش‌داده‌شده اضافه می‌شود.

notes.rewrite.<command>

هنگام بازنویسی کامیت‌ها با <command> (در حال حاضر amend یا rebase), اگر این متغیر false باشد، گیت یادداشت‌ها را از کامیت اصلی به کامیت بازنویسی‌شده کپی نخواهد کرد. پیش‌فرض true است. همچنین به notes.rewriteRef در ادامه مراجعه کنید.

این تنظیم را می‌توان با متغیر محیطی GIT_NOTES_REWRITE_REF که باید فهرستی از ارجاع‌ها یا globهای جداشده با دو نقطه باشد بازنویسی کرد.

notes.rewriteMode

هنگام کپی کردن یادداشت‌ها در حین بازنویسی (به گزینه notes.rewrite.<command> مراجعه فرمایید)، تعیین می‌کند در صورتی که کامیت مقصد از قبل دارای یادداشت باشد چه اقدامی انجام شود. باید یکی از موارد overwrite, concatenate, cat_sort_uniq, یا ignore باشد. پیش‌فرض concatenate است.

این تنظیم را می‌توان با متغیر محیطی GIT_NOTES_REWRITE_MODE بازنویسی کرد.

notes.rewriteRef

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

مقدار پیش‌فرض ندارد؛ برای فعال‌سازی بازنویسی یادداشت باید این متغیر را پیکربندی کنید. برای فعال کردن بازنویسی برای یادداشت‌های کامیت پیش‌فرض، آن را روی refs/notes/commits تنظیم فرمایید.

می‌تواند با متغیر محیطی GIT_NOTES_REWRITE_REF بازنویسی شود. برای شرح بیشتر قالب آن به notes.rewrite.<command> در بالا مراجعه کنید.

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

2026-06-29 Git 2.55.0