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

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

default, myers

minimal

patience

histogram

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

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

changes

lines

files

cumulative

<limit>

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

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

no

default

plain

blocks

zebra

dimmed-zebra

no

ignore-space-at-eol

ignore-space-change

ignore-all-space

allow-indentation-change

color

plain

porcelain

none

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

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

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

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

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

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

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

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

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

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

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

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

برای نشان دادن تفاوت بین -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)

<tree-ish>

--cached

--merge-base

-m

in-place edit  :100644 100644 bcd1234 0123456 M file0
copy-edit      :100644 100644 abcd123 1234567 C68 file1 file2
rename-edit    :100644 100644 abcd123 1234567 R86 file1 file3
create         :000000 100644 0000000 1234567 A file4
delete         :100644 000000 1234567 0000000 D file5
unmerged       :000000 000000 0000000 0000000 U file6

:100644 100644 5be4a4a 0000000 M file.c

::100644 100644 100644 fabadb8 cc95eb0 4866510 MM       desc.c
::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM       bar.sh
::100644 100644 100644 e07d6c5 9042e82 ee91881 RR       phooey.c

::100644 100644 100644 fabadb8 cc95eb0 4866510 MM       desc.c  desc.c  desc.c
::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM       foo.sh  bar.sh  bar.sh
::100644 100644 100644 e07d6c5 9042e82 ee91881 RR       fooey.c fuey.c  phooey.c

diff --git a/file1 b/file2

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

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

old mode <mode>
new mode <mode>
deleted file mode <mode>
new file mode <mode>
copy from <path>
copy to <path>
rename from <path>
rename to <path>
similarity index <number>
dissimilarity index <number>
index <hash>..<hash> <mode>

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

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

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

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

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

diff --combined file

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

diff --cc file

index <hash>,<hash>..<hash>
mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>

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

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

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

@@@ <from-file-range> <from-file-range> <to-file-range> @@@

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

arch/{i386 => x86}/Makefile    |   4 +--

1       2       README
3       1       arch/{i386 => x86}/Makefile

1       2       README NUL
3       1       NUL arch/i386/Makefile NUL arch/x86/Makefile NUL

show me the differences between HEAD and the current index
contents (the ones I'd write using 'git write-tree')

git diff-index --cached HEAD

torvalds@ppc970:~/git> git diff-index --cached HEAD
:100644 000000 4161aecc6700a2eb579e842af0b7f22b98443f74 0000000000000000000000000000000000000000 D    commit.c
:000000 100644 0000000000000000000000000000000000000000 4161aecc6700a2eb579e842af0b7f22b98443f74 A    git-commit.c

show me the differences between HEAD and the currently checked out
tree - index contents _and_ files that aren't up to date

torvalds@ppc970:~/v2.6/linux> git diff-index --abbrev HEAD
:100644 100644 7476bb5ba 000000000 M  kernel/sched.c

همانند سایر دستورات این نوع، git diff-index در واقع به هیچ وجه به محتوای فایل نگاه نمی‌کند. بنابراین شاید فایل kernel/sched.c واقعاً تغییری نکرده باشد و شما فقط آن را touch کرده باشید. در هر دو حالت، این یک یادآوری است مبنی بر اینکه باید git update-index را روی آن اجرا کنید تا ایندکس همگام شود.

می‌توانید ترکیبی از فایل‌ها داشته باشید که هم‌زمان به صورت «به‌روزرسانی شده» و «هنوز در دایرکتوری کاری دست‌خورده (dirty) است» ظاهر شوند. همیشه می‌توانید تشخیص دهید کدام فایل در کدام وضعیت است، زیرا موارد «به‌روزرسانی شده» یک شناسه sha1 معتبر نشان می‌دهند و موارد «ناهماهنگ با ایندکس» همیشه دارای شناسه sha1 ویژه تمام‌صفر خواهند بود.