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

git-format-rev - قالب‌بندی شناسه‌های ارجاع و بازبینی گیت

(EXPERIMENTAL!) git format-rev --stdin-mode=<mode> --format=<pretty> [--[no-]notes=<ref>] [-z] [--[no-]null-output] [--[no-]null-input]

قالب‌بندی سفارشی بازبینی‌ها (revisions) از ورودی استاندارد.

این دستور آزمایشی است. رفتار آن ممکن است در آینده تغییر کند.

--stdin-mode=<mode>

نحوه تفسیر داده‌های ورودی استاندارد:

revs

هر خط یا رکورد (بخش قالب ورودی و خروجی را ببینید) به عنوان یک کامیت تفسیر می‌شود. از هر نوع عبارت بازبینی می‌توان استفاده کرد (ببینید gitrevisions(7)). برچسب‌های حاشیه‌نویسی‌شده پوسته‌گیری (peel) می‌شوند (ببینید gitglossary(7)).

آرگومان rev نیز پذیرفته می‌شود.

text

تمام نام‌های اشیای کامیتِ یافت‌شده در متن آزاد را قالب‌بندی می‌کند. این‌ها باید نام‌های کامل شیء باشند؛ به این معنی که نام‌های شانزده‌شانزدهی (هگزادسیمال) کوتاه تفسیر نخواهند شد.

هر آنچه که به عنوان یک نام شیء تجزیه شود اما به عنوان شیء کامیت شناخته نشود، دست‌نخورده باقی می‌ماند (عیناً چاپ می‌شود).

--format=<pretty>

رشته قالب‌بندی سفارشی (pretty format).

--notes=<ref>, --no-notes

مرجع یادداشت‌های سفارشی. یادداشت‌ها هنگام استفاده از اتوم %N نمایش داده می‌شوند. ببینید git-notes(1).

-z, --null

استفاده از نویسه NUL برای خاتمه دادن به هر دو ورودی و خروجی به جای خط جدید (newline). این گزینه را نمی‌توان نفی کرد.

این گزینه زمانی مفید است که هم ورودی و هم خروجی بتوانند شامل خط جدید باشند یا ورودی این دستور نیز از نویسه NUL برای پایان خطوط استفاده کند؛ بخش قالب ورودی و خروجی در زیر را ببینید.

حالت --stdin-mode=text می‌تواند از این گزینه در مواردی که نیاز به پردازش ورودی‌هایی مانند git last-modified -z دارد استفاده کند؛ بخش مثال‌ها در زیر را ببینید.

--null-output, --no-null-output

استفاده از نویسه NUL برای پایان دادن به خروجی به جای خط جدید. حالت پیش‌فرض --no-null-output است.

این گزینه زمانی مفید است که خروجی ممکن است شامل خطوط جدید باشد، برای مثال اگر از اتوم %n (خط جدید) استفاده شود.

--null-input, --no-null-input

استفاده از نویسه NUL برای پایان دادن به ورودی به جای خط جدید. حالت پیش‌فرض --no-null-input است.

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

این دستور به‌طور پیش‌فرض از خط جدید برای پایان دادن به ورودی و خروجی استفاده می‌کند. برای استفاده از نویسه NUL به عنوان پایان‌دهنده، گزینه‌های -z، --null-output و --null-input را ببینید.

حالت --stdin-mode=revs یک کامیت قالب‌بندی‌شده را به همراه پایان‌دهنده در خروجی درج می‌کند. این را می‌توان یک خط یا یک رکورد نامید (در صورتی که واژه «خط» بیش از حد تداعی‌کننده پایان با خط جدید باشد).

توجه داشته باشید که این بدان معناست که نویسه پایان‌دهنده (خط جدید یا NUL) به عنوان یک پایان‌دهنده (terminator) عمل می‌کند، نه یک جداکننده (separator). به عبارت دیگر، آخرین خط یا رکورد نیز با نویسه پایان‌دهنده خاتمه می‌یابد.

حالت --stdin-mode=text هر نام شیء را با کامیت قالب‌بندی‌شده جایگزین می‌کند؛ به عنوان مثال قالب %s یک نام شیء کامیت را بدون هیچ نویسه پایانی به <subject> تبدیل می‌کند. مانند این:

Did we not fix this in "<subject>"?

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

دستور git-last-modified(1) کامیتی را نشان می‌دهد که هر فایل آخرین بار در آن تغییر یافته است.

$ git last-modified -- README.md Makefile
7798034171030be0909c56377a4e0e10e6d2df93        Makefile
c50fbb2dd225e7e82abba4380423ae105089f4d7        README.md

می‌توانیم خروجی را به این دستور هدایت (pipe) کنیم تا نام شیء با نویسنده کامیت جایگزین شود.

$ git last-modified -- README.md Makefile |
    git format-rev --stdin-mode=text --format=%an
Junio C Hamano  Makefile
Todd Zullinger  README.md

مثال دیگر قالب‌بندی کامیت‌ها در پیام‌های کامیت است. با فرض داشتن این پیام کامیت:

Fix off-by-one error
Fix off-by-one error introduced in
e83c5163316f89bfbde7d9ab23ca2e25604af290.
We thought we fixed this in 5569bf9bbedd63a00780fc5c110e0cfab3aa97b9 but
that only covered 1/3 of the faulty cases.

می‌توانیم کامیت‌ها را قالب‌بندی کرده و از par(1) برای بازآرایی متن استفاده کنیم، مثلاً در یک قلاب commit-msg:

$ git config set hook.reference-commits.event commit-msg
$ git config set hook.reference-commits.command reference-commits
$ cat $(which reference-commits)
#/bin/sh
msg="$1"
rewritten=$(mktemp)
git format-rev --stdin-mode=text --format=reference <"$msg" |
    par >"$rewritten"
mv "$rewritten" "$msg"

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

Fix off-by-one error
Fix off-by-one error introduced in e83c5163316 (Implement better memory
allocator, 2005-04-07).
We thought we fixed this in 5569bf9bbed (Fix memory allocator,
2005-06-22) but that only covered 1/3 of the faulty cases.

این دستور به شما امکان می‌دهد هر تعداد بازبینی را با هر ترتیبی تنها با یک بار اجرای دستور قالب‌بندی کنید. مورد git-last-modified(1) در بخش مثال‌های بالا را در نظر بگیرید:

1.ممکن است صدها فایل وجود داشته باشد
2.کامیت‌ها ممکن است تکراری باشند؛ یعنی دو یا چند فایل آخرین بار در یک کامیت یکسان تغییر کرده باشند

دو دستور پرکاربرد که کامیت‌ها را به شکل سفارشی قالب‌بندی می‌کنند git-log(1) و git-show(1) هستند. مشخص شده است که آن‌ها برای مورد کاربرد بالا چندان مناسب نیستند.

•خروجی git-last-modified(1) باید در چند مرحله پردازش شود، زیرا لازم است ستون اول را به صورت جداگانه تبدیل کرده و سپس نویسنده را به نام فایل پیوند دهید. اما این مشکل قابل حل است.
•می‌توانید هر کامیت را به git show یا git log --no-walk -1 بفرستید. اما این بدان معناست که باید برای هر خط یک فرآیند ایجاد کنید.
•فرض کنید می‌خواهید تنها از یک فرآیند استفاده کنید و نه یک فرآیند به ازای هر خط. بنابراین مایلید تمام کامیت‌ها را به دستور بفرستید. اکنون با این مشکل روبرو می‌شوید که قبل از دریافت هرگونه خروجی، باید تمامی کامیت‌ها را به دستورها وارد کنید (این حالت در مورد حالت‌های --stdin نیز صدق می‌کند). به عبارت دیگر، نمی‌توانید روی هر خط پیمایش کرده، نویسنده را برای آن کامیت به دست آورید و نام نویسنده و نام فایل را در خروجی بنویسید. لازم است تمامی کامیت‌ها را تغذیه کرده، تمام خروجی را دریافت نمایید و خروجی را با نام فایل تطبیق دهید.
•اما مشکل بعدی این است که دستورها داده‌های تکراری ورودی را حذف می‌کنند و هر کامیت را تنها یک بار در خروجی قرار می‌دهند. بنابراین نمی‌توانید ترتیب خروجی را با ترتیب ورودی مطابقت دهید، زیرا یک کامیت ممکن است در ورودی اصلی تکرار شده باشد.

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

git-name-rev(1), git-log(1).

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

2026-06-29 Git 2.55.0