GIT-BLAME(1) Git Manual GIT-BLAME(1)

git-blame - نمایش اینکه کدام ویرایش و نویسنده آخرین بار هر سطر از یک فایل را تغییر داده است

git blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
          [-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
          [--ignore-rev <rev>] [--ignore-revs-file <file>]
          [--color-lines] [--color-by-age] [--progress] [--abbrev=<n>]
          [ --contents <file> ] [<rev> | --reverse <rev>..<rev>] [--] <file>

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

هنگامی که یک یا چند بار مشخص شود، گزینه -L حاشیه‌نویسی را به سطرهای درخواستی محدود می‌کند.

مبدأ سطرها در تغییر نام‌های کامل فایل به طور خودکار دنبال می‌شود (در حال حاضر گزینه‌ای برای خاموش کردن دنبال کردن تغییر نام وجود ندارد). برای دنبال کردن سطرهایی که از یک فایل به فایل دیگر منتقل شده‌اند، یا سطرهایی که از فایلی دیگر کپی و چسبانده شده‌اند و غیره، گزینه‌های -C و -M را ببینید.

گزارش چیزی درباره سطرهایی که حذف شده یا جایگزین شده‌اند به شما نمی‌گوید؛ لازم است از ابزاری مانند git diff یا رابط «pickaxe» که به اختصار در بند بعدی آمده است استفاده کنید.

جدا از پشتیبانی حاشیه‌نویسی فایل، گیت همچنین از جستجو در تاریخچه توسعه برای یافتن زمانی که یک قطعه کد در یک تغییر رخ داده است، پشتیبانی می‌کند. این امر امکان ردیابی زمان اضافه شدن یک قطعه کد به یک فایل، جابجایی یا کپی شدن آن میان فایل‌ها، و در نهایت حذف یا جایگزین شدن آن را فراهم می‌سازد. این کار با جستجوی یک رشته متنی در diff انجام می‌شود. یک مثال کوچک از رابط pickaxe که به دنبال blame_usage می‌گردد:

$ git log --pretty=oneline -S'blame_usage'
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output

-b

برای کامیت‌های مرزی (boundary commits) یک SHA-1 خالی نشان می‌دهد. این مورد همچنین از طریق گزینه پیکربندی blame.blankBoundary قابل کنترل است.

--root

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

--show-stats

آمار اضافی را در پایان خروجی blame لحاظ می‌کند.

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

تنها محدوده خطوط مشخص‌شده توسط <start>,<end>، یا با عبارت باقاعده نام تابع <funcname> را حاشیه‌نویسی می‌کند. می‌تواند چندین بار مشخص شود. محدوده‌های دارای هم‌پوشانی مجاز هستند.

<start> و <end> اختیاری هستند. -L <start> یا -L <start>, از <start> تا انتهای فایل را در بر می‌گیرد. -L ,<end> از ابتدای فایل تا <end> را در بر می‌گیرد.

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

•<number>

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

•/<regex>/

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

•+<offset> یا -<offset>

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

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

-l

نمایش ویرایش (rev) طولانی (پیش‌فرض: غیرفعال).

-t

نمایش برچسب زمانی خام (پیش‌فرض: غیرفعال).

-S <revs-file>

استفاده از ویرایش‌های موجود در <revs-file> به جای فراخوانی git-rev-list(1).

--reverse <start>..<end>

پیمایش تاریخچه به سمت جلو به جای عقب. به جای نمایش ویرایشی که یک سطر در آن ظاهر شده است، آخرین ویرایشی که سطر در آن وجود داشته را نشان می‌دهد. این به محدوده‌ای از ویرایش‌ها مانند <start>..<end> نیاز دارد که در آن مسیر مورد بررسی در <start> وجود داشته باشد. git blame --reverse <start> برای راحتی به عنوان git blame --reverse <start>..HEAD در نظر گرفته می‌شود.

--first-parent

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

-p, --porcelain

نمایش با قالبی طراحی‌شده برای استفاده ماشین (پردازش خودکار).

--line-porcelain

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

--incremental

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

--encoding=<encoding>

کدگذاری مورد استفاده برای خروجی نام‌های نویسندگان و خلاصه‌های کامیت را مشخص می‌کند. تنظیم آن روی none باعث می‌شود blame داده‌ها را تبدیل‌نشده در خروجی قرار دهد. برای اطلاعات بیشتر، بحث مربوط به کدگذاری را در صفحه راهنمای git-log(1) ببینید.

--contents <file>

حاشیه‌نویسی با استفاده از محتویات <file>، با شروع از <rev> در صورت مشخص بودن، و در غیر این صورت از HEAD. می‌توانید - را مشخص کنید تا دستور محتویات فایل را از ورودی استاندارد بخواند.

--date <format>

قالب مورد استفاده برای نمایش تاریخ‌ها را مشخص می‌کند. اگر --date ارائه نشود، مقدار متغیر پیکربندی blame.date استفاده می‌شود. اگر متغیر پیکربندی blame.date نیز تنظیم نشده باشد، قالب iso به کار می‌رود. برای مقادیر پشتیبانی‌شده، بحث گزینه --date را در git-log(1) ببینید.

--progress, --no-progress

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

-M[<num>]

تشخیص سطرهای منتقل‌شده یا کپی‌شده در داخل یک فایل. هنگامی که یک کامیت بلوکی از سطرها را جابجا یا کپی می‌کند (برای مثال فایل اصلی دارای A و سپس B است، و کامیت آن را به B و سپس A تغییر می‌دهد)، الگوریتم سنتی blame تنها نیمی از جابجایی را متوجه می‌شود و معمولاً سطرهایی که به بالا منتقل شده‌اند (یعنی B) را به والد منتسب می‌کند و سطرهایی که به پایین منتقل شده‌اند (یعنی A) را به کامیت فرزند نسبت می‌دهد. با این گزینه، هر دو گروه از سطرها با اجرای مراحل بازرسی اضافی به والد منتسب می‌شوند.

<num> اختیاری است، اما کران پایینی برای تعداد نویسه‌های الفبایی-عددی است که گیت باید به عنوان جابجایی/کپی در یک فایل تشخیص دهد تا آن سطرها را به کامیت والد مرتبط سازد. مقدار پیش‌فرض ۲۰ است.

-C[<num>]

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

<num> اختیاری است، اما کران پایینی برای تعداد نویسه‌های الفبایی-عددی است که گیت باید به عنوان جابجایی/کپی میان فایل‌ها تشخیص دهد تا آن سطرها را به کامیت والد مرتبط سازد. و مقدار پیش‌فرض ۴۰ است. اگر بیش از یک گزینه -C داده شده باشد، آرگومان <num> آخرین -C اعمال خواهد شد.

--ignore-rev <rev>

هنگام انتساب blame، تغییرات ایجادشده توسط آن ویرایش را نادیده می‌گیرد، گویی که این تغییر هرگز رخ نداده است. سطرهایی که توسط یک کامیت نادیده‌گرفته‌شده تغییر یافته یا اضافه شده‌اند، به کامیت قبلی که آن سطر یا سطرهای مجاور را تغییر داده است منتسب خواهند شد. این گزینه ممکن است چندین بار برای نادیده گرفتن بیش از یک ویرایش مشخص شود. اگر گزینه پیکربندی blame.markIgnoredLines تنظیم شده باشد، سطرهایی که توسط یک کامیت نادیده‌گرفته‌شده تغییر کرده و به کامیت دیگری منتسب شده‌اند با یک ? در خروجی blame علامت‌گذاری می‌شوند. اگر گزینه پیکربندی blame.markUnblamableLines تنظیم شده باشد، آن سطرهایی که توسط یک کامیت نادیده‌گرفته‌شده دستکاری شده‌اند و نتوانسته‌ایم آن‌ها را به ویرایش دیگری منتسب کنیم با یک * علامت‌گذاری می‌شوند. در حالت‌های پورسلین، به ترتیب عبارت‌های ignored و unblamable در یک خط جدید چاپ می‌شوند.

--ignore-revs-file <file>

ویرایش‌های فهرست‌شده در <file> را نادیده می‌گیرد، که باید قالبی مشابه با یک fsck.skipList داشته باشد. این گزینه ممکن است تکرار شود، و این فایل‌ها پس از هر فایلی که با گزینه پیکربندی blame.ignoreRevsFile مشخص شده است پردازش خواهند شد. یک نام فایل خالی، ""، فهرست ویرایش‌های فایل‌های قبلاً پردازش‌شده را پاک خواهد کرد.

--color-lines

رنگ‌آمیزی حاشیه‌نویسی سطرها در قالب پیش‌فرض به شکلی متفاوت، در صورتی که از همان کامیت سطر قبلی آمده باشند. این کار تشخیص بلوک‌های کد معرفی‌شده توسط کامیت‌های مختلف را آسان‌تر می‌کند. رنگ پیش‌فرض فیروزه‌ای (cyan) است و می‌تواند با استفاده از گزینه پیکربندی color.blame.repeatedLines تنظیم شود.

--color-by-age

رنگ‌آمیزی حاشیه‌نویسی سطرها بر اساس سن سطر در قالب پیش‌فرض. گزینه پیکربندی color.blame.highlightRecent کنترل می‌کند که چه رنگی برای هر محدوده سنی استفاده شود.

-h

نمایش پیام راهنما.

-c

استفاده از همان حالت خروجی git-annotate(1) (پیش‌فرض: غیرفعال).

--score-debug

لحاظ کردن اطلاعات اشکال‌زدایی مربوط به جابجایی سطرها میان فایل‌ها (گزینه -C را ببینید) و سطرهای جابجاشده درون یک فایل (گزینه -M را ببینید). اولین عدد فهرست‌شده امتیاز است. این عدد تعداد نویسه‌های الفبایی-عددی تشخیص‌داده‌شده است که میان یا درون فایل‌ها منتقل شده‌اند. این مقدار باید بالاتر از آستانه معینی باشد تا git blame آن سطرهای کد را جابجاشده در نظر بگیرد.

-f, --show-name

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

-n, --show-number

نمایش شماره سطر در کامیت اصلی (پیش‌فرض: غیرفعال).

-s

حذف نام نویسنده و برچسب زمانی از خروجی.

-e, --show-email

نمایش ایمیل نویسنده به جای نام نویسنده (پیش‌فرض: غیرفعال). این مورد همچنین می‌تواند از طریق گزینه پیکربندی blame.showEmail کنترل شود.

-w

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

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

انتخاب الگوریتم تفاضل (diff). انواع آن به شرح زیر است:

default, myers

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

minimal

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

patience

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

histogram

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

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

--abbrev=<n>

به جای استفاده از ۷+۱ رقم هگزادسیمال پیش‌فرض به عنوان نام شیء مختصر، از <m>+1 رقم استفاده می‌کند، که در آن <m> حداقل <n> است اما یکتا بودن نام‌های اشیاء کامیت را تضمین می‌کند. توجه داشته باشید که ۱ ستون برای علامت هشتک (caret) جهت مشخص کردن کامیت مرزی استفاده می‌شود.

هنگامی که هیچ‌یک از گزینه‌های --porcelain یا --incremental مشخص نشده باشند، git blame حاشیه‌نویسی هر سطر را با موارد زیر خروجی می‌دهد:

•نام شیء مخفف‌شده برای کامیتی که سطر از آن آمده است؛
•شناسه نویسنده (به طور پیش‌فرض نام و تاریخ نویسنده، مگر اینکه -s یا -e مشخص شده باشد)؛ و
•شماره سطر

پیش از محتویات سطر.

در این قالب، هر سطر پس از یک هدر خروجی داده می‌شود؛ این هدر حداقل دارای خط اولی است که شامل موارد زیر است:

•شناسه SHA-1 چهل بایتی کامیتی که سطر به آن منتسب شده است؛
•شماره سطر در فایل اصلی؛
•شماره سطر در فایل نهایی؛
•در سطری که گروهی از سطرها از یک کامیت متفاوت نسبت به سطر قبلی را آغاز می‌کند، تعداد سطرهای این گروه. در سطرهای بعدی این فیلد وجود ندارد.

این خط هدر، حداقل یک بار برای هر کامیت با اطلاعات زیر دنبال می‌شود:

•نام نویسنده (author)، ایمیل (author-mail)، زمان (author-time)، و منطقه زمانی (author-tz)؛ و به طور مشابه برای ثبت‌کننده کامیت (committer).
•نام فایل در کامیتی که سطر به آن منتسب شده است.
•خط اول پیام لاگ کامیت (summary).

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

قالب پورسلین به طور کلی اطلاعات کامیتی را که قبلاً دیده شده است حذف می‌کند. برای مثال، دو سطر که به یک کامیت منتسب شده‌اند هر دو نشان داده خواهند شد، اما جزئیات مربوط به آن کامیت فقط یک بار نشان داده می‌شود. اطلاعاتی که مختص سطرهای منفرد هستند با یکدیگر گروه‌بندی نخواهند شد، مانند ویرایش‌هایی که قرار است به صورت ignored یا unblamable علامت‌گذاری شوند. این روش کارآمدتر است، اما ممکن است نیاز داشته باشد که وضعیت بیشتری توسط خواننده برنامه نگهداری شود. از گزینه --line-porcelain می‌توان برای خروجی دادن اطلاعات کامل کامیت برای هر سطر استفاده کرد، که امکان استفاده ساده‌تر (اما با کارایی کمتر) مانند زیر را فراهم می‌آورد:

# شمارش تعداد سطرهای منتسب به هر نویسنده
git blame --line-porcelain file |
sed -n 's/^author //p' |
sort | uniq -c | sort -rn

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

هنگامی که علاقه‌مند به یافتن مبدأ سطرهای ۴۰-۶۰ برای فایل foo هستید، می‌توانید از گزینه -L مانند زیر استفاده کنید (هر دو به یک معنا هستند — هر دو ۲۱ سطر را با شروع از سطر ۴۰ درخواست می‌کنند):

git blame -L 40,60 foo
git blame -L 40,+21 foo

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

git blame -L '/^sub hello {/,/^}$/' foo

که حاشیه‌نویسی را به بدنه زیرروال hello محدود می‌کند.

هنگامی که به تغییرات قدیمی‌تر از نسخه v2.6.18 یا تغییرات قدیمی‌تر از ۳ هفته علاقه‌مند نیستید، می‌توانید از مشخص‌کننده‌های محدوده ویرایش مشابه با git rev-list استفاده کنید:

git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo

هنگامی که از مشخص‌کننده‌های محدوده ویرایش برای محدود کردن حاشیه‌نویسی استفاده می‌شود، سطرهایی که از مرز محدوده تغییر نکرده‌اند (چه کامیت v2.6.18 و چه جدیدترین کامیتی که بیش از ۳ هفته قدمت دارد در مثال بالا) به همان کامیت مرز محدوده نسبت داده می‌شوند.

یک روش به ویژه مفید، بررسی این است که آیا یک فایل اضافه‌شده دارای سطرهایی است که با کپی و چسباندن از فایل‌های موجود ایجاد شده‌اند یا خیر. گاهی اوقات این نشان می‌دهد که توسعه‌دهنده بی‌دقت بوده و کد را به درستی بازآفرینی (refactor) نکرده است. ابتدا می‌توانید کامیتی را که فایل را معرفی کرده است پیدا کنید:

git log --diff-filter=A --pretty=short -- foo

و سپس با استفاده از نشانه‌گذاری commit^!، تغییر میان کامیت و والدین آن را حاشیه‌نویسی کنید:

git blame -C -C -f $commit^! -- foo

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

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

1.هر مدخل blame همیشه با خطی به شکل زیر آغاز می‌شود: 
<40-byte-hex-sha1> <sourceline> <resultline> <num-lines>

شماره سطرها از ۱ آغاز می‌شوند.

2.اولین باری که یک کامیت در جریان خروجی ظاهر می‌شود، اطلاعات گوناگون دیگری درباره آن چاپ می‌شود که با یک برچسب تک‌کلمه‌ای در ابتدای هر خط، اطلاعات اضافی کامیت (نویسنده، ایمیل، ثبت‌کننده کامیت، تاریخ‌ها، خلاصه و غیره) را توصیف می‌کند.
3.برخلاف قالب پورسلین، اطلاعات نام فایل همیشه ارائه می‌شود و مدخل را خاتمه می‌دهد: 
filename <whitespace-quoted-filename-goes-here>

و بنابراین تجزیه آن برای یک تجزیه‌کننده مبتنی بر خط و کلمه واقعاً بسیار ساده است (که برای اکثر زبان‌های اسکریپت‌نویسی بسیار طبیعی است).


یادداشت
برای کسانی که عمل تجزیه (parsing) را انجام می‌دهند: جهت مقاوم‌تر ساختن آن، کافی است هر خطی را میان خط اول و آخر (خطوط <40-byte-hex-sha1> و filename) که کلمات برچسب ابتدای خطوط «اطلاعات گسترده» آن را نمی‌شناسید (یا به آن مورد خاص اهمیتی نمی‌دهید) نادیده بگیرید. به این ترتیب، اگر اطلاعات جدیدی اضافه شود (مانند کدگذاری کامیت یا توضیحات گسترده کامیت)، نمایشگر blame با مشکلی مواجه نخواهد شد.

gitmailmap(5) را ببینید.

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

blame.blankBoundary

نمایش نام شیء کامیت خالی برای کامیت‌های مرزی در git-blame(1). این گزینه به صورت پیش‌فرض false است.

blame.coloring

طرح رنگ‌آمیزی مورد استفاده در خروجی blame را مشخص می‌کند. این مقدار می‌تواند repeatedLines، highlightRecent، یا none باشد که پیش‌فرض است.

blame.date

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

blame.showEmail

نمایش ایمیل نویسنده به جای نام نویسنده در git-blame(1). این گزینه به صورت پیش‌فرض false است.

blame.showRoot

عدم برخورد با کامیت‌های ریشه به عنوان مرز در git-blame(1). این گزینه به صورت پیش‌فرض false است.

blame.ignoreRevsFile

نادیده گرفتن ویرایش‌های فهرست‌شده در فایل، یک نام شیء مخفف‌نشده در هر خط، در git-blame(1). فاصله‌های خالی و توضیحاتی که با # آغاز می‌شوند نادیده گرفته خواهند شد. این گزینه ممکن است چندین بار تکرار شود. نام‌های فایل خالی فهرست ویرایش‌های نادیده‌گرفته‌شده را بازنشانی می‌کنند. این گزینه پیش از گزینه خط فرمان --ignore-revs-file پردازش خواهد شد.

blame.markUnblamableLines

علامت‌گذاری سطرهایی که توسط یک ویرایش نادیده‌گرفته‌شده تغییر یافته‌اند و نتوانسته‌ایم به کامیت دیگری منتسب کنیم با یک * در خروجی git-blame(1).

blame.markIgnoredLines

علامت‌گذاری سطرهایی که توسط یک ویرایش نادیده‌گرفته‌شده تغییر یافته‌اند و به کامیت دیگری منتسب شده‌اند با یک ? در خروجی git-blame(1).

git-annotate(1)

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

2026-06-29 Git 2.55.0