GIT-CONFIG(1) Git Manual GIT-CONFIG(1)

git-config - دریافت و تنظیم گزینه‌های مخزن یا سراسری

git config list [<file-option>] [<display-option>] [--includes]
git config get [<file-option>] [<display-option>] [--includes] [--all] [--regexp] [--value=<pattern>] [--fixed-value] [--default=<default>] [--url=<url>] <name>
git config set [<file-option>] [--type=<type>] [--all] [--value=<pattern>] [--fixed-value] <name> <value>
git config unset [<file-option>] [--all] [--value=<pattern>] [--fixed-value] <name>
git config rename-section [<file-option>] <old-name> <new-name>
git config remove-section [<file-option>] <name>
git config edit [<file-option>]
git config [<file-option>] --get-colorbool <name> [<stdout-is-tty>]

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

با استفاده از گزینه --append می‌توان چندین خط را به یک گزینه اضافه کرد. اگر می‌خواهید گزینه‌ای را که می‌تواند در چندین خط وجود داشته باشد به‌روزرسانی یا لغو کنید، باید --value=<pattern> (که یک عبارت منظم گسترش‌یافته است، مگر اینکه گزینه --fixed-value داده شده باشد) مشخص شود. تنها مقادیر موجودی که با الگو مطابقت دارند به‌روزرسانی یا لغو می‌شوند. اگر می‌خواهید خطوطی را مدیریت کنید که با الگو مطابقت ندارند، کافی است یک علامت تعجب منفرد در ابتدای آن قرار دهید (همچنین بخش «مثال‌ها (EXAMPLES)» را ببینید)، اما توجه داشته باشید که این کار تنها زمانی کار می‌کند که گزینه --fixed-value در حال استفاده نباشد.

گزینه --type=<type> به git config دستور می‌دهد تا اطمینان حاصل کند مقادیر ورودی و خروجی تحت <type> داده‌شده قابلیت استانداردسازی (canonicalize) دارند. اگر هیچ --type=<type> مشخص نشود، هیچ استانداردسازی انجام نخواهد شد. فراخوانندگان می‌توانند مشخص‌کننده موجود --type را با --no-type لغو کنند.

هنگام خواندن، مقادیر به صورت پیش‌فرض از فایل‌های پیکربندی سراسری سیستم (system)، سراسری کاربر (global) و محلی مخزن (local) خوانده می‌شوند، و می‌توان از گزینه‌های --system، --global، --local، --worktree و --file <filename> استفاده کرد تا به دستور گفته شود فقط از همان مکان بخواند (بخش «فایل‌ها (FILES)» را ببینید).

هنگام نوشتن، مقدار جدید به صورت پیش‌فرض در فایل پیکربندی محلی مخزن نوشته می‌شود، و می‌توان از گزینه‌های --system، --global، --worktree و --file <filename> استفاده کرد تا به دستور گفته شود در آن مکان بنویسد (می‌توانید --local را مشخص کنید اما این حالت پیش‌فرض است).

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

•بخش یا کلید نامعتبر است (ret=1)،
•هیچ بخش یا نامی ارائه نشده است (ret=2)،
•فایل پیکربندی نامعتبر است (ret=3)،
•نوشتن در فایل پیکربندی امکان‌پذیر نیست (ret=4)،
•تلاش برای لغو گزینه‌ای که وجود ندارد (ret=5)،
•تلاش برای لغو/تنظیم گزینه‌ای که چندین خط با آن مطابقت دارند (ret=5)، یا
•تلاش برای استفاده از عبارت منظم نامعتبر (ret=6).

در صورت موفقیت، این دستور با کد خروج 0 خارج می‌شود.

فهرستی از تمام متغیرهای پیکربندی موجود را می‌توان با استفاده از دستور git help --config به دست آورد.

list

فهرست کردن تمام متغیرهای تنظیم‌شده در فایل پیکربندی، همراه با مقادیر آن‌ها.

get

مقدار کلید مشخص‌شده را برمی‌گرداند. اگر کلید چندین بار در پیکربندی وجود داشته باشد، آخرین مقدار را برمی‌گرداند. اگر --all مشخص شده باشد، تمام مقادیر مرتبط با کلید را برمی‌گرداند. اگر کلید وجود نداشته باشد، کد خطای 1 را برمی‌گرداند.

set

تنظیم مقدار برای یک یا چند گزینه پیکربندی. به صورت پیش‌فرض، این دستور از نوشتن گزینه‌های پیکربندی چندمقداری خودداری می‌کند. ارسال --all تمام گزینه‌های پیکربندی چندمقداری را با مقدار جدید جایگزین می‌کند، در حالی که --value= تمام گزینه‌های پیکربندی را که مقادیرشان با الگوی داده‌شده مطابقت دارد جایگزین خواهد کرد.

unset

لغو مقدار برای یک یا چند گزینه پیکربندی. به صورت پیش‌فرض، این دستور از لغو کلیدهای چندمقداری خودداری می‌کند. ارسال --all تمام گزینه‌های پیکربندی چندمقداری را لغو می‌کند، در حالی که --value تمام گزینه‌های پیکربندی را که مقادیرشان با الگوی داده‌شده مطابقت دارد لغو خواهد کرد.

rename-section

تغییر نام بخش داده‌شده به نام جدید.

remove-section

حذف بخش داده‌شده از فایل پیکربندی.

edit

یک ویرایشگر را برای تغییر فایل پیکربندی مشخص‌شده باز می‌کند؛ شامل --system، --global، --local (پیش‌فرض)، --worktree، یا --file <config-file>.

--replace-all

رفتار پیش‌فرض، جایگزینی حداکثر یک خط است. این گزینه تمام خطوط منطبق با کلید (و به صورت اختیاری --value=<pattern>) را جایگزین می‌کند.

--append

بدون تغییر هیچ‌یک از مقادیر موجود، یک خط جدید به گزینه اضافه می‌کند. این کار همانند ارائه --value=^$ در set است.

--comment <message>

افزودن یک توضیح (کامنت) در انتهای خطوط جدید یا تغییریافته.

اگر <message> با یک یا چند نویسه فاصله و به دنبال آن # شروع شود، همان‌طور که هست استفاده می‌شود. اگر با # شروع شود، پیش از استفاده یک فاصله به ابتدای آن اضافه می‌شود. در غیر این صورت، رشته " # " (یک فاصله و سپس علامت هش و سپس یک فاصله) به ابتدای آن اضافه خواهد شد. رشته حاصل بلافاصله پس از مقدار تعریف‌شده برای متغیر قرار می‌گیرد. <message> نباید حاوی نویسه‌های خط جدید (linefeed) باشد (توضیحات چندخطی مجاز نیستند).

--all

همراه با get، تمام مقادیر یک کلید چندمقداری را برمی‌گرداند.

--regexp

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

--url=<URL>

هنگامی که یک <name> دوبخشی به صورت <section>.<key> داده شود، مقداری برای <section>.<URL>.<key> که بخش <URL> آن بهترین تطابق را با URL داده‌شده دارد برگردانده می‌شود (اگر چنین کلیدی وجود نداشته باشد، مقدار <section>.<key> به عنوان جایگزین استفاده می‌شود). هنگامی که فقط <section> به عنوان نام داده شود، این کار برای تمام کلیدهای آن بخش انجام شده و فهرست می‌شوند. در صورتی که مقداری پیدا نشود کد خطای 1 را برمی‌گرداند.

--global

برای گزینه‌های نوشتن: به جای فایل .git/config مخزن، در فایل سراسری ~/.gitconfig می‌نویسد، یا در فایل $XDG_CONFIG_HOME/git/config اگر این فایل موجود باشد و فایل ~/.gitconfig وجود نداشته باشد.

برای گزینه‌های خواندن: به جای تمام فایل‌های موجود، فقط از فایل سراسری ~/.gitconfig و از $XDG_CONFIG_HOME/git/config می‌خواند.

همچنین بخش «فایل‌ها (FILES)» را ببینید.

--system

برای گزینه‌های نوشتن: به جای فایل .git/config مخزن، در فایل سراسری سیستم $(prefix)/etc/gitconfig می‌نویسد.

برای گزینه‌های خواندن: به جای تمام فایل‌های موجود، فقط از فایل سراسری سیستم $(prefix)/etc/gitconfig می‌خواند.

همچنین بخش «فایل‌ها (FILES)» را ببینید.

--local

برای گزینه‌های نوشتن: در فایل .git/config مخزن می‌نویسد. این رفتار پیش‌فرض است.

برای گزینه‌های خواندن: به جای تمام فایل‌های موجود، فقط از فایل .git/config مخزن می‌خواند.

همچنین بخش «فایل‌ها (FILES)» را ببینید.

--worktree

مشابه --local است، به جز اینکه اگر extensions.worktreeConfig فعال باشد، از $GIT_DIR/config.worktree خوانده یا در آن نوشته می‌شود. در غیر این صورت همانند --local خواهد بود. توجه داشته باشید که $GIT_DIR برای درخت کاری اصلی برابر با $GIT_COMMON_DIR است، اما برای سایر درخت‌های کاری به شکل $GIT_DIR/worktrees/<id>/ است. برای یادگیری نحوه فعال‌سازی extensions.worktreeConfig به git-worktree(1) مراجعه کنید.

-f <config-file>, --file <config-file>

برای گزینه‌های نوشتن: به جای فایل .git/config مخزن، در فایل مشخص‌شده می‌نویسد.

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

همچنین بخش «فایل‌ها (FILES)» را ببینید.

--blob <blob>

مشابه --file است اما به جای فایل از blob داده‌شده استفاده می‌کند. برای مثال می‌توانید از master:.gitmodules برای خواندن مقادیر از فایل .gitmodules در شاخه master استفاده کنید. برای فهرست کامل‌تری از روش‌های نگارش نام‌های blob، بخش «SPECIFYING REVISIONS» در gitrevisions(7) را ببینید.

--value=<pattern>, --no-value

همراه با get، set و unset، تنها با <pattern> تطبیق داده می‌شود. این الگو یک عبارت منظم گسترش‌یافته است مگر اینکه --fixed-value داده شده باشد.

از --no-value برای لغو <pattern> استفاده کنید.

--fixed-value

هنگامی که همراه با --value=<pattern> استفاده شود، با <pattern> به عنوان یک رشته دقیق به جای عبارت منظم رفتار می‌کند. این کار جفت‌های نام/مقداری را که مطابقت داده می‌شوند تنها به مواردی محدود می‌کند که مقدار دقیقاً برابر با <pattern> باشد.

--type <type>

دستور git config اطمینان حاصل خواهد کرد که هر ورودی یا خروجی تحت محدودیت(های) نوع داده‌شده معتبر باشد، و مقادیر خروجی را به شکل استاندارد <type>'s تبدیل خواهد کرد.

انواع معتبر <type>'s عبارتند از:

•bool: استانداردسازی مقادیر true، yes، on و اعداد مثبت به عنوان "true"، و مقادیر false، no، off و 0 به عنوان "false".
•int: استانداردسازی مقادیر به صورت اعداد ده‌دهی ساده. یک پسوند اختیاری از k، m یا g باعث می‌شود که مقدار در هنگام ورودی در 1024، 1048576 یا 1073741824 ضرب شود.
•bool-or-int: استانداردسازی بر اساس bool یا int، همان‌طور که در بالا توضیح داده شد.
•path: استانداردسازی با گسترش ~ ابتدایی به مقدار $HOME و ~user به دایرکتوری خانگی کاربر مشخص‌شده. این مشخص‌کننده هنگام تنظیم مقدار هیچ اثری ندارد (اما می‌توانید از git config section.variable ~/ از خط فرمان استفاده کنید تا پوسته شما عمل گسترش را انجام دهد.)
•expiry-date: استانداردسازی با تبدیل از یک رشته تاریخ ثابت یا نسبی به یک برچسب زمان (timestamp). این مشخص‌کننده هنگام تنظیم مقدار هیچ اثری ندارد.
•color: هنگام دریافت مقدار، با تبدیل به یک توالی گریز رنگ ANSI استانداردسازی می‌شود. هنگام تنظیم مقدار، یک بررسی صحت انجام می‌شود تا اطمینان حاصل شود که مقدار داده‌شده به عنوان یک رنگ ANSI قابلیت استانداردسازی دارد، اما همان‌طور که هست نوشته می‌شود.

اگر دستور در حالت list باشد، آنگاه آرگومان --type <type> برای هر مقدار پیکربندی فهرست‌شده اعمال خواهد شد. اگر مقدار با موفقیت در آن قالب تجزیه نشود، از فهرست حذف خواهد شد.

--bool, --int, --bool-or-int, --path, --expiry-date

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

--no-type

مشخص‌کننده نوعی را که پیش‌تر تنظیم شده بود لغو می‌کند (اگر پیش‌تر تنظیم شده باشد). این گزینه درخواست می‌کند که git config متغیر بازیابی‌شده را استانداردسازی نکند. --no-type بدون --type=<type> یا --<type> هیچ اثری ندارد.

-z, --null

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

--name-only

تنها نام‌های متغیرهای پیکربندی را برای list یا get خروجی می‌دهد.

--show-names, --no-show-names

همراه با get، کلیدهای پیکربندی را علاوه بر مقادیر آن‌ها نشان می‌دهد. حالت پیش‌فرض --no-show-names است، مگر اینکه --url داده شده باشد و هیچ زیربخشی در <name> وجود نداشته باشد.

--show-origin

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

--show-scope

مشابه --show-origin است از این نظر که خروجی تمام گزینه‌های پیکربندی پرس‌وجوشده را با محدوده (scope) آن مقدار (worktree، local، global، system، command) تکمیل می‌کند.

--get-colorbool <name> [<stdout-is-tty>]

تنظیمات رنگ را برای <name> (برای مثال color.diff) پیدا کرده و "true" یا "false" را خروجی می‌دهد. <stdout-is-tty> باید "true" یا "false" باشد، و هنگامی که پیکربندی روی "auto" باشد در نظر گرفته می‌شود. اگر <stdout-is-tty> وجود نداشته باشد، خروجی استاندارد خود دستور را بررسی می‌کند و اگر قرار باشد از رنگ استفاده شود با وضعیت 0 خارج می‌شود، و در غیر این صورت با وضعیت 1 خارج می‌شود. هنگامی که تنظیمات رنگ برای name تعریف نشده باشد، دستور از color.ui به عنوان پشتیبان استفاده می‌کند.

--includes, --no-includes

دستورالعمل‌های include.* را در فایل‌های پیکربندی هنگام جستجوی مقادیر رعایت می‌کند. هنگام مشخص شدن یک فایل خاص (برای مثال، با استفاده از --file، --global و غیره) به طور پیش‌فرض روی off و هنگام جستجو در تمام فایل‌های پیکربندی روی on قرار دارد.

--default <value>

هنگام استفاده از get، اگر متغیر درخواستی یافت نشود، به گونه‌ای رفتار می‌کند که گویی <value> مقدار تخصیص‌یافته به آن متغیر است.

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

git config <name>

جایگزین‌شده با git config get <name>.

git config <name> <value> [<value-pattern>]

جایگزین‌شده با git config set [--value=<pattern>] <name> <value>.

-l, --list

جایگزین‌شده با git config list.

--get <name> [<value-pattern>]

جایگزین‌شده با git config get [--value=<pattern>] <name>.

--get-all <name> [<value-pattern>]

جایگزین‌شده با git config get [--value=<pattern>] --all <name>.

--get-regexp <name-regexp>

جایگزین‌شده با git config get --all --show-names --regexp <name-regexp>.

--get-urlmatch <name> <URL>

جایگزین‌شده با git config get --url=<URL> <name>.

--get-color <name> [<default>]

جایگزین‌شده با git config get --type=color [--default=<default>] <name>.

--add <name> <value>

جایگزین‌شده با git config set --append <name> <value>.

--unset <name> [<value-pattern>]

جایگزین‌شده با git config unset [--value=<pattern>] <name>.

--unset-all <name> [<value-pattern>]

جایگزین‌شده با git config unset [--value=<pattern>] --all <name>.

--rename-section <old-name> <new-name>

جایگزین‌شده با git config rename-section <old-name> <new-name>.

--remove-section <name>

جایگزین‌شده با git config remove-section <name>.

-e, --edit

جایگزین‌شده با git config edit.

مقدار pager.config تنها هنگام فهرست کردن پیکربندی رعایت می‌شود، یعنی هنگام استفاده از list یا get که ممکن است چندین نتیجه را برگردانند. حالت پیش‌فرض استفاده از صفحه‌بند (pager) است.

به صورت پیش‌فرض، git config گزینه‌های پیکربندی را از چندین فایل خواهد خواند:

$(prefix)/etc/gitconfig

فایل پیکربندی سراسری سیستم.

$XDG_CONFIG_HOME/git/config, ~/.gitconfig

فایل‌های پیکربندی مختص کاربر. هنگامی که متغیر محیطی XDG_CONFIG_HOME تنظیم نشده باشد یا خالی باشد، $HOME/.config/ به عنوان $XDG_CONFIG_HOME استفاده می‌شود.

به این فایل‌ها همچنین فایل‌های پیکربندی «سراسری» (global) گفته می‌شود. اگر هر دو فایل وجود داشته باشند، هر دو فایل به ترتیبی که در بالا ذکر شد خوانده می‌شوند.

$GIT_DIR/config

فایل پیکربندی مختص مخزن.

$GIT_DIR/config.worktree

این فایل اختیاری است و تنها زمانی جستجو می‌شود که extensions.worktreeConfig در $GIT_DIR/config وجود داشته باشد.

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

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

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

به صورت پیش‌فرض، گزینه‌ها تنها در فایل پیکربندی مختص مخزن نوشته می‌شوند. توجه داشته باشید که این موضوع بر گزینه‌هایی مانند set و unset نیز اثر می‌گذارد. git config در هر بار فقط یک فایل را تغییر خواهد داد.

می‌توانید منابع پیکربندی قابل خواندن یا نوشتن را با مشخص کردن مسیر یک فایل با گزینه --file، یا با مشخص کردن یک محدوده پیکربندی با --system، --global، --local یا --worktree محدود کنید. برای اطلاعات بیشتر، بخش «گزینه‌ها (OPTIONS)» در بالا را ببینید.

هر منبع پیکربندی درون یک محدوده (scope) پیکربندی قرار می‌گیرد. این محدوده‌ها عبارتند از:

system

$(prefix)/etc/gitconfig

global

$XDG_CONFIG_HOME/git/config

~/.gitconfig

local

$GIT_DIR/config

worktree

$GIT_DIR/config.worktree

command

متغیرهای محیطی GIT_CONFIG_{COUNT,KEY,VALUE} (بخش «متغیرهای محیطی (ENVIRONMENT)» در زیر را ببینید)

گزینه -c

به استثنای command، هر محدوده متناظر با یک گزینه خط فرمان است: --system، --global، --local، --worktree.

هنگام خواندن گزینه‌ها، تعیین یک محدوده تنها گزینه‌ها را از فایل‌های درون آن محدوده می‌خواند. هنگام نوشتن گزینه‌ها، تعیین یک محدوده در فایل‌های درون آن محدوده خواهد نوشت (به جای فایل پیکربندی مختص مخزن). برای توضیحات کامل بخش «گزینه‌ها (OPTIONS)» در بالا را ببینید.

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

پیکربندی محافظت‌شده به محدوده‌های system، global و command اشاره دارد. به دلایل امنیتی، گزینه‌های خاصی تنها زمانی رعایت می‌شوند که در پیکربندی محافظت‌شده مشخص شده باشند، و در غیر این صورت نادیده گرفته می‌شوند.

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

GIT_CONFIG_GLOBAL, GIT_CONFIG_SYSTEM

پیکربندی را به جای پیکربندی در سطح سراسری (global) یا سطح سیستم (system) از فایل‌های داده‌شده دریافت می‌کند. برای جزئیات به git(1) مراجعه کنید.

GIT_CONFIG_NOSYSTEM

اینکه آیا خواندن تنظیمات از فایل سراسری سیستم $(prefix)/etc/gitconfig نادیده گرفته شود یا خیر. برای جزئیات به git(1) مراجعه کنید.

همچنین بخش «فایل‌ها (FILES)» را ببینید.

GIT_CONFIG_COUNT, GIT_CONFIG_KEY_<n>, GIT_CONFIG_VALUE_<n>

اگر GIT_CONFIG_COUNT روی یک عدد مثبت تنظیم شده باشد، تمام جفت‌های محیطی GIT_CONFIG_KEY_<n> و GIT_CONFIG_VALUE_<n> تا آن عدد به پیکربندی زمان اجرای فرایند اضافه خواهند شد. جفت‌های پیکربندی با اندیس صفر شروع می‌شوند. هر کلید یا مقدار مفقود به عنوان یک خطا در نظر گرفته می‌شود. یک GIT_CONFIG_COUNT خالی همانند GIT_CONFIG_COUNT=0 در نظر گرفته می‌شود، یعنی هیچ جفتی پردازش نخواهد شد. این متغیرهای محیطی مقادیر موجود در فایل‌های پیکربندی را بازنویسی (override) خواهند کرد، اما توسط هر گزینه صریحی که از طریق git -c ارسال شود بازنویسی می‌شوند.

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

GIT_CONFIG

اگر هیچ گزینه --file به git config ارائه نشود، از فایل ارائه‌شده توسط GIT_CONFIG به گونه‌ای استفاده می‌کند که گویی از طریق --file ارائه شده است. این متغیر هیچ اثری بر سایر دستورات گیت ندارد و عمدتاً برای سازگاری گذشته حفظ شده است؛ به طور کلی هیچ دلیلی برای استفاده از آن به جای گزینه --file وجود ندارد.

با فرض یک فایل .git/config مانند این:

#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#
; core variables
[core]
        ; Don't trust file modes
        filemode = false
; Our diff algorithm
[diff]
        external = /usr/local/bin/diff-wrapper
        renames = true
; Proxy settings
[core]
        gitproxy=proxy-command for kernel.org
        gitproxy=default-proxy ; for all the rest
; HTTP
[http]
        sslVerify
[http "https://weak.example.com"]
        sslVerify = false
        cookieFile = /tmp/cookie.txt

می‌توانید filemode را با دستور زیر روی true تنظیم کنید:

% git config set core.filemode true

مدخل‌های فرضی دستور پروکسی در واقع دارای یک پسوند هستند تا مشخص شود برای چه URL اعمال می‌شوند. در اینجا نحوه تغییر مدخل برای kernel.org به "ssh" آمده است:

% git config set --value='for kernel.org$' core.gitproxy '"ssh" for kernel.org'

این کار اطمینان حاصل می‌کند که تنها جفت کلید/مقدار مربوط به kernel.org جایگزین شود.

برای حذف مدخل renames، این دستور را اجرا کنید:

% git config unset diff.renames

اگر می‌خواهید مدخلی را برای یک متغیر چندمقداری (مانند core.gitproxy در بالا) حذف کنید، باید یک عبارت منظم ارائه دهید که دقیقاً با مقدار یک خط مطابقت داشته باشد.

برای پرس‌وجوی مقدار یک کلید مشخص، این دستور را اجرا کنید:

% git config get core.filemode

یا، برای پرس‌وجوی یک متغیر چندمقداری:

% git config get --value="for kernel.org$" core.gitproxy

اگر می‌خواهید تمام مقادیر یک متغیر چندمقداری را بدانید، دستور زیر را اجرا کنید:

% git config get --all --show-names core.gitproxy

اگر اهل ریسک هستید، می‌توانید تمام مقادیر core.gitproxy را با یک مقدار جدید جایگزین کنید:

% git config set --all core.gitproxy ssh

با این حال، اگر واقعاً فقط می‌خواهید خط مربوط به پروکسی پیش‌فرض را جایگزین کنید، یعنی خطی که پسوند "for ..." ندارد، کاری شبیه به این انجام دهید:

% git config set --value='! for ' core.gitproxy ssh

برای تطبیق واقعی تنها مقادیری که دارای علامت تعجب هستند، باید به این صورت عمل کنید:

% git config set --value='[!]' section.key value

برای افزودن یک پروکسی جدید، بدون تغییر هیچ‌یک از گزینه‌های موجود، از این دستور استفاده کنید:

% git config set --append core.gitproxy '"proxy-command" for example.com'

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

#!/bin/sh
WS=$(git config get --type=color --default="blue reverse" color.diff.whitespace)
RESET=$(git config get --type=color --default="reset" "")
echo "${WS}your whitespace color or blue reverse${RESET}"

برای نشانی‌های وب در https://weak.example.com، مقدار http.sslVerify روی false تنظیم شده است، در حالی که برای سایر نشانی‌ها روی true تنظیم شده است:

% git config get --type=bool --url=https://good.example.com http.sslverify
true
% git config get --type=bool --url=https://weak.example.com http.sslverify
false
% git config get --url=https://weak.example.com http
http.cookieFile /tmp/cookie.txt
http.sslverify false

فایل پیکربندی گیت شامل تعدادی متغیر است که بر رفتار دستورات گیت تأثیر می‌گذارند. فایل‌های .git/config و به صورت اختیاری config.worktree (بخش "CONFIGURATION FILE" از git-worktree(1) را ببینید) در هر مخزن برای ذخیره پیکربندی آن مخزن استفاده می‌شوند، و $HOME/.gitconfig برای ذخیره یک پیکربندی به ازای هر کاربر به عنوان مقادیر پشتیبان برای فایل .git/config استفاده می‌شود. فایل /etc/gitconfig می‌تواند برای ذخیره یک پیکربندی پیش‌فرض در سطح سیستم استفاده شود.

متغیرهای پیکربندی هم توسط دستورات سطح پایین (plumbing) و هم دستورات سطح بالا (porcelain) گیت استفاده می‌شوند. این متغیرها به بخش‌ها تقسیم شده‌اند، که در آن نام کامل متغیر، آخرین بخش جداشده با نقطه است و نام بخش، تمام چیزهای قبل از آخرین نقطه می‌باشد. نام متغیرها به حروف بزرگ و کوچک حساس نیستند، تنها حروف الفبایی-عددی و - را مجاز می‌دانند، و باید با یک نویسه الفبایی آغاز شوند. برخی از متغیرها ممکن است چندین بار ظاهر شوند؛ در این حالت می‌گوییم که متغیر چندمقداری است.

قواعد نحوی نسبتاً انعطاف‌پذیر و آسان‌گیرانه است. نویسه‌های فاصله سفید، که در این زمینه شامل نویسه فاصله (SP) و تب افقی (HT) هستند، عمدتاً نادیده گرفته می‌شوند. نویسه‌های # و ; آغازگر توضیحات تا پایان خط هستند. خطوط خالی نادیده گرفته می‌شوند.

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

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

[section "subsection"]

نام‌های زیربخش‌ها به حروف بزرگ و کوچک حساس هستند و می‌توانند شامل هر نویسه‌ای به جز خط جدید و بایت تهی (null) باشند. گیومه دوتایی " و بک‌اسلش را می‌توان به ترتیب با اسکیپ کردن آن‌ها به صورت \" و \\ گنجاند. بک‌اسلش‌های قبل از سایر نویسه‌ها هنگام خواندن حذف می‌شوند؛ برای مثال، \t به صورت t و \0 به صورت 0 خوانده می‌شود. سربرگ‌های بخش نمی‌توانند در چندین خط امتداد یابند. متغیرها ممکن است مستقیماً به یک بخش یا به یک زیربخش مشخص تعلق داشته باشند. در صورت داشتن [section "subsection"] می‌توانید [section] را نیز داشته باشید، اما الزامی به آن نیست.

همچنین یک نحو منسوخ‌شده [section.subsection] وجود دارد. با این نحو، نام زیربخش به حروف کوچک تبدیل شده و همچنین به صورت حساس به حروف بزرگ و کوچک مقایسه می‌شود. این نام‌های زیربخش از همان محدودیت‌های نام‌های بخش پیروی می‌کنند.

تمام خطوط دیگر (و باقی‌مانده خط پس از سربرگ بخش) به عنوان متغیرهای تنظیم‌کننده شناخته می‌شوند، به شکل name = value (یا صرفاً name که یک میان‌بر برای بیان این است که متغیر دارای مقدار بولی "true" است). نام‌های متغیرها به حروف بزرگ و کوچک حساس نیستند، تنها نویسه‌های الفبایی-عددی و - را مجاز می‌دانند، و باید با یک نویسه الفبایی آغاز شوند.

نویسه‌های فاصله سفید در اطراف name، = و value دور ریخته می‌شوند. فاصله‌های سفید داخلی درون value عیناً حفظ می‌شوند. توضیحاتی که با # یا ; شروع شده و تا پایان خط امتداد می‌یابند دور ریخته می‌شوند. خطی که مقداری را تعریف می‌کند می‌تواند با پایان یافتن با یک بک‌اسلش (\) به خط بعدی ادامه یابد؛ بک‌اسلش و نویسه‌های پایان خط دور ریخته می‌شوند.

اگر value نیاز دارد که دارای نویسه‌های فاصله سفید ابتدایی یا انتهایی باشد، باید در گیومه دوتایی (") محصور شود. در داخل گیومه دوتایی، نویسه‌های گیومه دوتایی (") و بک‌اسلش (\) باید اسکیپ شوند: از \" برای " و \\ برای \ استفاده کنید.

توالی‌های گریز زیر (علاوه بر \" و \\) شناخته شده‌اند: \n برای نویسه خط جدید (NL)، \t برای تب افقی (HT, TAB) و \b برای پس‌بر (BS). سایر توالی‌های گریز نویسه (شامل توالی‌های گریز هشت‌هشتی) نامعتبر هستند.

بخش‌های include و includeIf به شما امکان می‌دهند دستورالعمل‌های پیکربندی را از منبع دیگری درج کنید. این بخش‌ها عملکرد یکسانی با یکدیگر دارند با این استثنا که بخش‌های includeIf ممکن است در صورتی که شرط آن‌ها به true ارزیابی نشود نادیده گرفته شوند؛ بخش «درج‌های مشروط (Conditional includes)» در زیر را ببینید.

می‌توانید با تنظیم متغیر ویژه include.path (یا includeIf.*.path) به نام فایلی که قرار است درج شود، یک فایل پیکربندی را از فایل دیگری درج کنید. این متغیر یک نام مسیر را به عنوان مقدار خود می‌پذیرد و مشمول گسترش مد (tilde expansion) است. این متغیرها را می‌توان چندین بار مشخص کرد.

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

می‌توانید با تنظیم یک متغیر includeIf.<condition>.path به نام فایلی که قرار است درج شود، یک فایل پیکربندی را به صورت مشروط از فایل دیگری درج کنید.

شرط با یک کلمه کلیدی آغاز می‌شود و به دنبال آن یک دونقطه (:) و سپس داده‌هایی قرار می‌گیرد که قالب و معنای آن‌ها به کلمه کلیدی بستگی دارد. کلمات کلیدی پشتیبانی‌شده عبارتند از:

gitdir

داده‌هایی که بعد از کلمه کلیدی gitdir و دونقطه می‌آیند به عنوان یک الگوی تطبیق مسیر (glob) استفاده می‌شوند. اگر مکان دایرکتوری .git با این الگو مطابقت داشته باشد، شرط درج برآورده می‌شود.

مکان .git ممکن است به صورت خودکار شناسایی شود یا از متغیر محیطی $GIT_DIR به دست آید. اگر مخزن از طریق یک فایل .git شناسایی شود (برای مثال از زیرماژول‌ها یا یک درخت کاری پیوند داده‌شده)، مکان .git مکان نهایی خواهد بود که دایرکتوری .git در آن قرار دارد، نه مکانی که فایل .git در آن است.

الگو می‌تواند شامل نویسه‌های عام استاندارد globbing و دو نویسه اضافی، **/ و /** باشد که می‌توانند چندین جزء مسیر را مطابقت دهند. لطفاً برای جزئیات به gitignore(5) مراجعه کنید. جهت سهولت:

•اگر الگو با ~/ آغاز شود، ~ با محتوای متغیر محیطی HOME جایگزین خواهد شد.
•اگر الگو با ./ آغاز شود، با دایرکتوری حاوی فایل پیکربندی فعلی جایگزین می‌شود.
•اگر الگو با هیچ‌کدام از ~/، ./ یا / آغاز نشود، **/ به صورت خودکار به ابتدای آن اضافه خواهد شد. برای مثال، الگوی foo/bar تبدیل به **/foo/bar می‌شود و با /any/path/to/foo/bar مطابقت خواهد داشت.
•اگر الگو با / پایان یابد، ** به صورت خودکار اضافه خواهد شد. برای مثال، الگوی foo/ تبدیل به foo/** می‌شود. به عبارت دیگر، با "foo" و هر آنچه در داخل آن است به صورت بازگشتی مطابقت خواهد داشت.

gitdir/i

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

onbranch

داده‌هایی که بعد از کلمه کلیدی onbranch و دونقطه می‌آیند به عنوان الگویی با نویسه‌های عام استاندارد globbing و دو نویسه اضافی، **/ و /** در نظر گرفته می‌شوند که می‌توانند چندین جزء مسیر را مطابقت دهند. اگر در یک درخت کاری باشیم که در آن نام شاخه فعلی چک‌اوت‌شده با الگو مطابقت داشته باشد، شرط درج برآورده می‌شود.

اگر الگو با / پایان یابد، ** به صورت خودکار اضافه خواهد شد. برای مثال، الگوی foo/ تبدیل به foo/** می‌شود. به عبارت دیگر، با تمام شاخه‌هایی که با foo/ آغاز می‌شوند مطابقت دارد. این مورد زمانی مفید است که شاخه‌های شما به صورت سلسله‌مراتبی سازماندهی شده باشند و بخواهید یک پیکربندی را برای تمام شاخه‌ها در آن سلسله‌مراتب اعمال کنید.

hasconfig:remote.*.url

داده‌هایی که بعد از این کلمه کلیدی و دونقطه می‌آیند به عنوان الگویی با نویسه‌های عام استاندارد globbing و دو نویسه اضافی، **/ و /** در نظر گرفته می‌شوند که می‌توانند چندین جزء را مطابقت دهند. نخستین باری که این کلمه کلیدی دیده شود، باقی‌مانده فایل‌های پیکربندی برای یافتن URLهای ریموت اسکن خواهند شد (بدون اعمال هیچ‌گونه مقداری). اگر حداقل یک URL ریموت وجود داشته باشد که با این الگو مطابقت کند، شرط درج برآورده می‌شود.

فایل‌هایی که توسط این گزینه درج می‌شوند (به طور مستقیم یا غیرمستقیم) مجاز نیستند حاوی URLهای ریموت باشند.

توجه داشته باشید که برخلاف سایر شرایط includeIf، حل این شرط متکی بر اطلاعاتی است که در زمان خواندن شرط هنوز مشخص نیست. یک مورد استفاده معمول این است که این گزینه در یک پیکربندی سطح سیستم یا سطح سراسری وجود داشته باشد، و URL ریموت در یک پیکربندی سطح محلی باشد؛ از این رو هنگام حل این شرط نیاز به پیش‌اسکن است. به منظور اجتناب از مسئله «مرغ و تخم‌مرغ» که در آن فایل‌های به طور بالقوه درج‌شده می‌توانند بر اینکه آیا چنین فایل‌هایی به طور بالقوه درج می‌شوند یا خیر اثر بگذارند، گیت با منع این فایل‌ها از اثرگذاری بر حل این شرایط (و در نتیجه منع آن‌ها از اعلان URLهای ریموت)، این چرخه را می‌شکند.

در مورد نام‌گذاری این کلمه کلیدی، این نام‌گذاری برای سازگاری آینده با طرح نام‌گذاری‌ای است که از شرایط درج مبتنی بر متغیرهای بیشتر پشتیبانی کند، اما در حال حاضر گیت تنها از همان کلمه کلیدی دقیق توضیح‌داده‌شده در بالا پشتیبانی می‌کند.

چند نکته بیشتر در مورد تطبیق از طریق gitdir و gitdir/i:

•پیوندهای نمادین (Symlinks) در $GIT_DIR پیش از تطبیق حل نمی‌شوند.
•هر دو نسخه پیوند نمادین و مسیر واقعی (realpath) در خارج از $GIT_DIR مطابقت داده خواهند شد. برای مثال اگر git/~ یک پیوند نمادین به mnt/storage/git/ باشد، هر دو gitdir:~/git و gitdir:/mnt/storage/git مطابقت خواهند داشت.

این موضوع در نسخه اولیه این قابلیت در v2.13.0 وجود نداشت، که تنها نسخه مسیر واقعی را مطابقت می‌داد. پیکربندی‌ای که می‌خواهد با نسخه اولیه این قابلیت سازگار باشد باید یا تنها نسخه مسیر واقعی را مشخص کند، یا هر دو نسخه را.

•توجه داشته باشید که "../" خاص نیست و به صورت لفظی مطابقت داده خواهد شد، که احتمالاً چیزی نیست که شما می‌خواهید.

# Core variables
[core]
        ; Don't trust file modes
        filemode = false
# Our diff algorithm
[diff]
        external = /usr/local/bin/diff-wrapper
        renames = true
[branch "devel"]
        remote = origin
        merge = refs/heads/devel
# Proxy settings
[core]
        gitProxy="ssh" for "kernel.org"
        gitProxy=default-proxy ; for the rest
[include]
        path = /path/to/foo.inc ; include by absolute path
        path = foo.inc ; find "foo.inc" relative to the current file
        path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
; include if $GIT_DIR is /path/to/foo/.git
[includeIf "gitdir:/path/to/foo/.git"]
        path = /path/to/foo.inc
; include for all repositories inside /path/to/group
[includeIf "gitdir:/path/to/group/"]
        path = /path/to/foo.inc
; include for all repositories inside $HOME/to/group
[includeIf "gitdir:~/to/group/"]
        path = /path/to/foo.inc
; relative paths are always relative to the including
; file (if the condition is true); their location is not
; affected by the condition
[includeIf "gitdir:/path/to/group/"]
        path = foo.inc
; include only if we are in a worktree where foo-branch is
; currently checked out
[includeIf "onbranch:foo-branch"]
        path = foo.inc
; include only if a remote with the given URL exists (note
; that such a URL may be provided later in a file or in a
; file read after this file is read, as seen in this example)
[includeIf "hasconfig:remote.*.url:https://example.com/**"]
        path = foo.inc
[remote "origin"]
        url = https://example.com/git

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

boolean

هنگامی که گفته می‌شود یک متغیر مقدار بولی (boolean) می‌پذیرد، مترادف‌های متعددی برای true و false پذیرفته می‌شوند؛ تمامی این موارد غیرحساس به حروف بزرگ و کوچک هستند.

true

مقدارهای لیترال برای true بولی عبارتند از yes، on، true و 1. همچنین، متغیری که بدون = <value> تعریف شود به عنوان true در نظر گرفته می‌شود.

false

مقدارهای لیترال برای false بولی عبارتند از no، off، false، 0 و رشته خالی.

هنگام تبدیل یک مقدار به شکل استاندارد آن با استفاده از مشخص‌کننده نوع --type=bool، git config اطمینان حاصل خواهد کرد که خروجی "true" یا "false" باشد (نوشته‌شده با حروف کوچک).

integer

مقدار بسیاری از متغیرها که اندازه‌های مختلف را مشخص می‌کنند می‌تواند با پسوندهای k، M و غیره همراه باشد تا به معنای «مقیاس‌بندی عدد در 1024»، «در 1024x1024» و غیره باشد.

color

مقدار متغیری که یک رنگ را می‌پذیرد، فهرستی از رنگ‌ها (حداکثر دو رنگ، یکی برای پیش‌زمینه و یکی برای پس‌زمینه) و ویژگی‌ها (هر تعداد که بخواهید) است که با فاصله از هم جدا شده‌اند.

رنگ‌های پایه‌ای پذیرفته‌شده عبارتند از normal، black، red، green، yellow، blue، magenta، cyan، white و default. اولین رنگ داده‌شده برای پیش‌زمینه و دومین رنگ برای پس‌زمینه است. تمام رنگ‌های پایه به جز normal و default دارای یک حالت روشن (bright) هستند که می‌توان با افزودن پیشوند bright به رنگ، مانند brightred، آن‌ها را مشخص کرد.

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

رنگ default به طور صریح رنگ را به حالت پیش‌فرض ترمینال بازنشانی می‌کند، برای مثال برای مشخص کردن یک پس‌زمینه پاک‌شده. اگرچه این مورد بین ترمینال‌ها متفاوت است، اما معمولاً مشابه تنظیم روی "white black" نیست.

رنگ‌ها همچنین می‌توانند به عنوان اعدادی بین 0 تا 255 داده شوند؛ این رنگ‌ها از حالت 256 رنگی ANSI استفاده می‌کنند (اما توجه داشته باشید که ممکن است همه ترمینال‌ها از آن پشتیبانی نکنند). اگر ترمینال شما پشتیبانی کند، می‌توانید مقادیر RGB بیست‌وچهار بیتی را نیز به صورت هگزادسیمال مشخص کنید، مانند #ff0ab3، یا مقادیر RGB دوازده بیتی مانند #f1b که معادل رنگ 24 بیتی #ff11bb است.

ویژگی‌های پذیرفته‌شده عبارتند از bold، dim، ul، blink، reverse، italic و strike (برای خط‌خورده یا حروفی با خط روی آن‌ها). موقعیت هر ویژگی نسبت به رنگ‌ها (قبل، بعد یا در بین آن‌ها) اهمیتی ندارد. ویژگی‌های خاص را می‌توان با افزودن پیشوند no یا no- (مانند noreverse، no-ul و غیره) غیرفعال کرد.

شبه‌ویژگی reset تمام رنگ‌ها و ویژگی‌ها را پیش از اعمال رنگ‌آمیزی مشخص‌شده بازنشانی می‌کند. برای مثال، reset green باعث یک پیش‌زمینه سبز و پس‌زمینه پیش‌فرض بدون هیچ ویژگی فعالی خواهد شد.

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

برای جایگاه‌های رنگی پیش‌تعریف‌شده در گیت، ویژگی‌ها به گونه‌ای در نظر گرفته شده‌اند که در ابتدای هر مورد در خروجی رنگی بازنشانی شوند. بنابراین تنظیم color.decorate.branch روی black آن نام شاخه را به رنگ ساده black درمی‌آورد، حتی اگر مورد قبلی در همان خط خروجی (مانند پرانتز بازکننده قبل از فهرست نام‌های شاخه‌ها در خروجی log --decorate) تنظیم شده باشد که با bold یا ویژگی دیگری رنگ‌آمیزی شود. با این حال، قالب‌های سفارشی لاگ ممکن است رنگ‌آمیزی‌های پیچیده‌تر و لایه‌بندی‌شده‌ای انجام دهند و حالت‌های منفی‌شده ممکن است در آنجا مفید باشند.

pathname

به متغیری که مقدار pathname (نام مسیر) را می‌پذیرد می‌توان رشته‌ای داد که با "~/" یا "~user/" آغاز می‌شود، و گسترش معمولی مد (tilde) برای چنین رشته‌ای رخ می‌دهد: ~/ به مقدار $HOME و ~user/ به دایرکتوری خانگی کاربر مشخص‌شده گسترش می‌یابد.

اگر یک مسیر با %(prefix)/ آغاز شود، باقی‌مانده آن به عنوان یک مسیر نسبی به «پیشوند زمان اجرا» (runtime prefix) گیت، یعنی نسبت به مکانی که گیت در آن نصب شده است، تفسیر می‌شود. برای مثال، %(prefix)/bin/ به دایرکتوری‌ای اشاره دارد که فایل اجرایی گیت در آن قرار دارد. اگر گیت بدون پشتیبانی از پیشوند زمان اجرا کامپایل شده باشد، پیشوند کامپایل‌شده به جای آن جایگزین خواهد شد. در صورت نادری که نیاز باشد یک مسیر لفظی مشخص شود که نباید not گسترش یابد، لازم است پیشوند ./ به آن اضافه شود، مانند: ./%(prefix)/bin.

اگر با پیشوند :(optional) همراه باشد، در صورتی که مسیر نام‌برده وجود نداشته باشد، با متغیر پیکربندی به گونه‌ای رفتار می‌شود که گویی وجود ندارد.

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

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

add.ignoreErrors, add.ignore-errors (منسوخ‌شده)

به git add می‌گوید زمانی که برخی از فایل‌ها به دلیل خطاهای ایندکس‌گذاری قابل افزودن نیستند، به افزودن فایل‌ها ادامه دهد. معادل گزینه --ignore-errors در git-add(1). add.ignore-errors منسوخ شده است، زیرا از قرارداد نام‌گذاری معمول برای متغیرهای پیکربندی پیروی نمی‌کند.

advice.*

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

از آنجا که این پیام‌ها برای کمک به کاربران انسانی در نظر گرفته شده‌اند، در خروجی خطای استاندارد (standard error) چاپ می‌شوند. هنگامی که ابزارهایی که Git را به عنوان یک زیرفرآیند اجرا می‌کنند آن‌ها را مخل می‌دانند، می‌توانند GIT_ADVICE=0 را در محیط تنظیم کنند تا تمام پیام‌های راهنما بی‌صدا شوند.

addEmbeddedRepo

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

addEmptyPathspec

زمانی نشان داده می‌شود که کاربر git add را بدون ارائه پارامتر مشخصه مسیر (pathspec) اجرا می‌کند.

addIgnoredFile

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

amWorkDir

زمانی نشان داده می‌شود که git-am(1) در اعمال یک فایل وصله ناموفق است، تا مکان فایل را به کاربر اطلاع دهد.

ambiguousFetchRefspec

زمانی نشان داده می‌شود که یک مشخصه مرجع واکشی (fetch refspec) برای چند ریموت به همان فضای نام شاخه ردیابی ریموت (remote-tracking branch) نگاشت می‌شود و باعث شکست در راه‌اندازی ردیابی شاخه می‌گردد.

checkoutAmbiguousRemoteBranchName

زمانی نشان داده می‌شود که آرگومان داده‌شده به git-checkout(1) و git-switch(1) به طور مبهم به یک شاخه ردیابی ریموت در بیش از یک ریموت حل‌وفصل می‌شود، در شرایطی که یک آرگومان غیرمبهم در غیر این صورت باعث تحویل گرفتن (checkout) یک شاخه ردیابی ریموت می‌شد. برای چگونگی تنظیم یک ریموت معین برای استفاده پیش‌فرض در برخی شرایطی که این راهنما چاپ می‌شود، متغیر پیکربندی checkout.defaultRemote را ببینید.

commitBeforeMerge

زمانی نشان داده می‌شود که git-merge(1) برای جلوگیری از رونویسی تغییرات محلی، از ادغام خودداری می‌کند.

detachedHead

زمانی نشان داده می‌شود که کاربر از git-switch(1) یا git-checkout(1) برای رفتن به وضعیت HEAD جداشده (detached HEAD) استفاده می‌کند، تا نحوه ایجاد یک شاخه محلی را پس از وقوع به کاربر بگوید.

diverging

زمانی نشان داده می‌شود که فوروارد سریع (fast-forward) امکان‌پذیر نیست.

fetchShowForcedUpdates

زمانی نشان داده می‌شود که git-fetch(1) زمان زیادی را صرف محاسبه به‌روزرسانی‌های اجباری پس از به‌روزرسانی مراجع می‌کند، یا برای هشدار دادن درباره اینکه این بررسی غیرفعال است.

forceDeleteBranch

زمانی نشان داده می‌شود که کاربر تلاش می‌کند شاخه‌ای را که به طور کامل ادغام نشده است بدون تنظیم گزینه اجبار (force) حذف کند.

ignoredHook

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

implicitIdentity

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

mergeConflict

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

nestedTag

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

pushAlreadyExists

زمانی نشان داده می‌شود که git-push(1) به‌روزرسانی‌ای را که شرایط فوروارد سریع را ندارد رد می‌کند (مانند یک تگ).

pushFetchFirst

زمانی نشان داده می‌شود که git-push(1) به‌روزرسانی‌ای را که سعی دارد یک مرجع ریموت اشاره‌کننده به شیئی را که ما نداریم رونویسی کند، رد می‌نماید.

pushNeedsForce

زمانی نشان داده می‌شود که git-push(1) به‌روزرسانی‌ای را که قصد دارد یک مرجع ریموت اشاره‌کننده به شیئی غیر از شبه‌کامیت (commit-ish) را رونویسی کند، یا باعث شود مرجع ریموت به شیئی که شبه‌کامیت نیست اشاره کند، رد می‌نماید.

pushNonFFCurrent

زمانی نشان داده می‌شود که git-push(1) به دلیل به‌روزرسانی غیر فوروارد سریع (non-fast-forward) در شاخه فعلی با شکست مواجه می‌شود.

pushNonFFMatching

زمانی نشان داده می‌شود که کاربر git-push(1) را اجرا کرده و مراجع منطبق («matching refs») را به صراحت ارسال نموده است (یعنی از : استفاده کرده، یا مشخصه مرجعی را تعیین نموده که شاخه فعلی نیست) و این کار منجر به خطای غیر فوروارد سریع شده است.

pushRefNeedsUpdate

زمانی نشان داده می‌شود که git-push(1) به‌روزرسانی اجباری یک شاخه را رد می‌کند هنگامی که مرجع ردیابی ریموت آن دارای به‌روزرسانی‌هایی است که ما به صورت محلی نداریم.

pushUnqualifiedRefname

زمانی نشان داده می‌شود که git-push(1) از تلاش برای حدس زدن فضای نام مرجع ریموتی که مبدأ به آن تعلق دارد بر اساس مراجع مبدأ و مقصد منصرف می‌شود، اما در جایی که هنوز می‌توانیم بر اساس نوع شیء مبدأ به کاربر پیشنهاد دهیم که به refs/heads/* یا refs/tags/* ارسال کند.

pushUpdateRejected

این متغیر را روی false تنظیم کنید اگر می‌خواهید pushNonFFCurrent، pushNonFFMatching، pushAlreadyExists، pushFetchFirst، pushNeedsForce و pushRefNeedsUpdate را به طور همزمان غیرفعال کنید.

rebaseTodoError

زمانی نشان داده می‌شود که پس از ویرایش فهرست کارهای بازسازی (rebase todo list) خطایی رخ دهد.

refSyntax

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

resetNoRefresh

زمانی نشان داده می‌شود که git-reset(1) برای بازخوانی ایندکس پس از ریست بیش از ۲ ثانیه طول می‌کشد، تا به کاربر بگوید می‌تواند از گزینه --no-refresh استفاده کند.

resolveConflict

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

rmHints

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

sequencerInUse

زمانی نشان داده می‌شود که یک دستور توالی‌ساز (sequencer) در حال حاضر در حال اجرا است.

skippedCherryPicks

زمانی نشان داده می‌شود که git-rebase(1) کامیتی را که قبلاً به صورت گلچین (cherry-pick) بر روی شاخه بالادست اعمال شده نادیده می‌گیرد.

sparseIndexExpanded

زمانی نشان داده می‌شود که یک ایندکس پراکنده (sparse index) به یک ایندکس کامل گسترش می‌یابد، که احتمالاً به دلیل وجود مجموعه‌ای غیرمنتظره از فایل‌ها در خارج از تحویل پراکنده (sparse-checkout) است.

statusAheadBehind

زمانی نشان داده می‌شود که git-status(1) تعداد جلو/عقب بودن (ahead/behind) یک مرجع محلی را در مقایسه با مرجع ردیابی ریموت آن محاسبه می‌کند و این محاسبه بیش از حد انتظار طول می‌کشد. اگر status.aheadBehind روی false باشد یا گزینه --no-ahead-behind داده شود ظاهر نخواهد شد.

statusHints

راهنمایی‌هایی درباره نحوه ادامه کار از وضعیت فعلی را در خروجی git-status(1)، در الگوی نمایش داده‌شده هنگام نوشتن پیام کامیت در git-commit(1)، و در پیام راهنمای نمایش داده‌شده توسط git-switch(1) یا git-checkout(1) هنگام جابجایی شاخه‌ها نمایش می‌دهد.

statusUoption

زمانی نشان داده می‌شود که git-status(1) برای شمارش فایل‌های ردیابی‌نشده بیش از ۲ ثانیه طول می‌کشد، تا به کاربر بگوید می‌تواند از گزینه -u استفاده کند.

submoduleAlternateErrorStrategyDie

زمانی نشان داده می‌شود که تنظیم گزینه submodule.alternateErrorStrategy روی «die» باعث بروز یک خطای مهلک (fatal) می‌شود.

submoduleMergeConflict

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

submodulesNotUpdated

زمانی نشان داده می‌شود که کاربر دستور زیرماژولی را اجرا می‌کند که به دلیل عدم اجرای git submodule update --init با شکست مواجه می‌شود.

suggestDetachingHead

زمانی نشان داده می‌شود که git-switch(1) از جدا کردن HEAD بدون گزینه صریح --detach خودداری می‌کند.

updateSparsePath

زمانی نشان داده می‌شود که از git-add(1) یا git-rm(1) خواسته می‌شود ورودی‌های ایندکس خارج از تحویل پراکنده (sparse checkout) فعلی را به‌روزرسانی کنند.

waitingForEditor

زمانی نشان داده می‌شود که Git منتظر ورودی ویرایشگر است. به عنوان مثال زمانی کاربرد دارد که ویرایشگر در داخل ترمینال اجرا نمی‌شود.

worktreeAddOrphan

زمانی نشان داده می‌شود که کاربر تلاش می‌کند یک درخت کاری (worktree) را از روی یک مرجع نامعتبر ایجاد کند، تا به کاربر بگوید چگونه به جای آن یک شاخه متولدنشده (unborn) جدید ایجاد کند.

alias.*, alias.*.command

نام‌های مستعار دستور برای بسته‌بند دستور git(1). نام‌های مستعار را می‌توان با استفاده از دو نحو تعریف کرد:
1.بدون زیربخش (subsection)، برای مثال: [alias] co = checkout. نام مستعار (در این مثال «co») به نویسه‌های الفبایی-عددی ASCII و - محدود است و بدون حساسیت به حروف بزرگ و کوچک مطابقت داده می‌شود.
2.با یک زیربخش، برای مثال: [alias "co"] command = checkout. نام مستعار می‌تواند شامل هر نویسه‌ای (به جز خط جدید و بایت‌های NUL) باشد، از جمله UTF-8، و به صورت بایت‌های خام و با حساسیت به حروف بزرگ و کوچک مطابقت داده می‌شود. شما عمل نام مستعار را در command تعریف می‌کنید.

مثال‌ها:

# Without subsection (ASCII alphanumeric and dash only)
[alias]
    co = checkout
    st = status
# With subsection (allows any characters, including UTF-8)
[alias "hämta"]
    command = fetch
[alias "rätta till"]
    command = commit --amend

با تعریف یک نام مستعار گیت، به عنوان مثال:

$ git config --global alias.last "cat-file commit HEAD"
# Which is equivalent to
$ git config --global alias.last.command "cat-file commit HEAD"

دستور git last معادل است با git cat-file commit HEAD.

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

توجه داشته باشید که کلمه اول یک نام مستعار لزوماً نباید یک دستور باشد. می‌تواند یک گزینه خط فرمان باشد که به فراخوانی git ارسال می‌شود. به ویژه، این قابلیت هنگام استفاده با -c برای ارسال پیکربندی‌های یک‌باره یا -p برای اجبار به صفحه‌بندی خروجی مفید است. برای مثال، loud-rebase = -c commit.verbose=true rebase را می‌توان طوری تعریف کرد که اجرای git loud-rebase معادل با git -c commit.verbose=true rebase باشد. همچنین، ps = -p status یک نام مستعار مفید خواهد بود، زیرا git ps خروجی git status را صفحه‌بندی می‌کند در حالی که دستور اصلی این کار را انجام نمی‌دهد.

اگر ابتدای بسط نام مستعار با یک علامت تعجب همراه باشد، به عنوان یک دستور شل در نظر گرفته می‌شود. برای مثال، با تعریف alias.new = !gitk --all --not ORIG_HEAD، فراخوانی git new معادل با اجرای دستور شل gitk --all --not ORIG_HEAD خواهد بود. توجه:

•دستورات شل از پوشه سطح بالای (top-level) مخزن اجرا خواهند شد، که لزوماً پوشه فعلی نیست.
•مقدار GIT_PREFIX همان‌طور که از اجرای git rev-parse --show-prefix از پوشه فعلی اولیه بازگردانده می‌شود تنظیم می‌گردد. git-rev-parse(1) را ببینید.
•نام‌های مستعار دستور شل همیشه آرگومان‌های اضافی ارائه‌شده به خط فرمان Git را به عنوان آرگومان‌های موضعی (positional arguments) دریافت می‌کنند.
•اگر نام مستعار شل شما یک اسکریپت «یک‌خطی» با چند دستور است (مثلاً در یک خط‌لوله)، به چندین آرگومان ارجاع می‌دهد، یا به هر نحو قادر به مدیریت آرگومان‌های موضعی اضافه‌شده در انتها نیست، باید دقت به خرج دهید. برای مثال: alias.cmd = "!echo $1 | grep $2" که به صورت git cmd 1 2 فراخوانی شود، به این شکل اجرا خواهد شد: echo $1 | grep $2 1 2، که مورد نظر شما نیست.
•یک راه مناسب برای رفع این مشکل این است که عملیات اسکریپت خود را در یک تابع درون‌خطی (inline function) بنویسید که سپس با هر آرگومان ارائه‌شده از خط فرمان فراخوانی شود. برای مثال: alias.cmd = "!c() { echo $1 | grep $2 ; }; c" مثال قبلی را به درستی اجرا خواهد کرد.
•تنظیم GIT_TRACE=1 می‌تواند به شما در اشکال‌زدایی دستوری که برای نام مستعارتان اجرا می‌شود کمک کند.

am.keepcr

اگر true باشد، git-am(1) برای وصله‌ها در قالب mbox، git-mailsplit(1) را با پارامتر --keep-cr فراخوانی می‌کند. در این حالت git-mailsplit(1) کاراکتر \r را از خطوطی که به \r\n ختم می‌شوند حذف نمی‌کند. با ارائه --no-keep-cr از خط فرمان قابل بازنویسی است.

am.threeWay

به طور پیش‌فرض، اگر وصله به طور تمیز اعمال نشود، git-am(1) با شکست مواجه خواهد شد. اگر روی true تنظیم شود، این تنظیم به git-am(1) می‌گوید که در صورت ثبت هویت حباب‌ها (blobs) در وصله که قرار است روی آن‌ها اعمال شود و در صورت در دسترس بودن محلی آن حباب‌ها، به ادغام ۳-طرفه (3-way merge) بازگردد (معادل دادن گزینه --3way از خط فرمان). مقدار پیش‌فرض false است.

am.messageId

هنگام استفاده از git-am(1)، یک دنباله (trailer) با عنوان Message-ID بر اساس سرآیند ایمیل به کامیت اضافه می‌کند (به git-interpret-trailers(1) مراجعه کنید). همچنین گزینه‌های --message-id و --no-message-id را ببینید.

apply.ignoreWhitespace

زمانی که روی change تنظیم شود، به git apply می‌گوید که تغییرات در فاصله‌های خالی (whitespace) را نادیده بگیرد، همانند گزینه --ignore-space-change. هنگامی که روی یکی از مقادیر: no، none، never، false تنظیم شود، به git apply می‌گوید تمام تفاوت‌های فاصله‌های خالی را رعایت کند. به git-apply(1) مراجعه کنید.

apply.whitespace

به git apply می‌گوید که چگونه فاصله‌های خالی را مدیریت کند، همانند گزینه --whitespace. به git-apply(1) مراجعه کنید.

attr.tree

مرجعی به یک درخت (tree) در مخزن که ویژگی‌ها به جای فایل .gitattributes در درخت کاری از آن خوانده شود. اگر مقدار به یک شیء درخت معتبر حل‌وفصل نشود، به جای آن یک درخت خالی استفاده می‌شود. هنگامی که متغیر محیطی GIT_ATTR_SOURCE یا گزینه خط فرمان --attr-source استفاده شوند، این متغیر پیکربندی هیچ اثری ندارد.

یادداشت (Note)

گزینه‌های پیکربندی در bitmapPseudoMerge.* آزمایشی (EXPERIMENTAL) در نظر گرفته می‌شوند و ممکن است در آینده دستخوش تغییر شده یا به طور کامل حذف شوند. برای اطلاعات بیشتر درباره ویژگی نگاشت‌بیتی شبه‌ادغام (pseudo-merge bitmap)، بخش «Pseudo-merge bitmaps» در gitpacking(7) را ببینید.

bitmapPseudoMerge.<name>.pattern

عبارت منظم مورد استفاده برای تطبیق نام‌های مرجع. کامیت‌هایی که توسط مراجع منطبق با این الگو اشاره می‌شوند (و معیارهای زیر را برآورده می‌کنند، مانند bitmapPseudoMerge.<name>.sampleRate و bitmapPseudoMerge.<name>.threshold) برای گنجاندن در یک نگاشت‌بیتی شبه‌ادغام در نظر گرفته خواهند شد.

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

درون یک گروه شبه‌ادغام، کامیت‌ها ممکن است بر اساس گروه‌های تسخیر (capture groups) در الگو، بیشتر به زیرگروه‌ها تقسیم شوند. این زیرگروه‌بندی‌ها از عبارات منظم با الحاق هر گروه تسخیر از عبارت منظم، با یک خط تیره - در این میان تشکیل می‌شوند.

برای مثال، اگر الگو refs/tags/ باشد، آنگاه تمام تگ‌ها (به شرطی که معیارهای زیر را برآورده کنند) به عنوان نامزدهای همان گروه شبه‌ادغام در نظر گرفته می‌شوند. اما اگر الگو در عوض refs/remotes/([0-9])+/tags/ باشد، آنگاه تگ‌های ریموت‌های مختلف بر اساس شماره ریموت در گروه‌های شبه‌ادغام جداگانه دسته‌بندی خواهند شد.

bitmapPseudoMerge.<name>.decay

نرخی را تعیین می‌کند که با آن گروه‌های نگاشت‌بیتی شبه‌ادغام متوالی اندازه خود را کاهش می‌دهند. باید نامنفی باشد. این پارامتر را می‌توان به عنوان k در تابع f(n) = C * n^-k در نظر گرفت، که در آن f(n) اندازه گروه n-اُم است.

تنظیم نرخ زوال (decay rate) برابر با 0 باعث می‌شود همه گروه‌ها اندازه یکسانی داشته باشند. تنظیم نرخ زوال برابر با 1 باعث می‌شود گروه n-اُم اندازه‌ای معادل `1/n` اندازه گروه اولیه داشته باشد. مقادیر بالاتر نرخ زوال باعث می‌شود که گروه‌های متوالی با نرخ فزاینده‌ای کوچک‌تر شوند. مقدار پیش‌فرض 1 است.

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

bitmapPseudoMerge.<name>.sampleRate

نسبت کامیت‌های بدون نگاشت‌بیتی (در میان نوک‌های مرجع) را که برای گنجاندن در یک نگاشت‌بیتی شبه‌ادغام ناپایدار انتخاب می‌شوند تعیین می‌کند. باید بزرگ‌تر از 0 و کوچک‌تر یا مساوی با 1 باشد. مقدار پیش‌فرض 1 است.

bitmapPseudoMerge.<name>.threshold

حداقل سن کامیت‌های بدون نگاشت‌بیتی (در میان نوک‌های مرجع، مانند بالا) را که نامزد گنجاندن در یک نگاشت‌بیتی شبه‌ادغام ناپایدار هستند تعیین می‌کند. مقدار پیش‌فرض 1.week.ago است.

bitmapPseudoMerge.<name>.maxMerges

حداکثر تعداد کامیت‌های شبه‌ادغام را که کامیت‌ها ممکن است در میان آن‌ها توزیع شوند تعیین می‌کند.

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

برای مثال، اگر گروه تسخیر شما refs/tags/ باشد، این تنظیم تمام تگ‌ها را حداکثر در maxMerges کامیت شبه‌ادغام توزیع می‌کند. با این حال، اگر گروه تسخیر شما مثلاً refs/remotes/([0-9]+)/tags/ باشد، این تنظیم برای مجموعه تگ‌های هر ریموت به طور جداگانه اعمال خواهد شد.

باید نامنفی باشد. مقدار پیش‌فرض 64 است.

bitmapPseudoMerge.<name>.stableThreshold

حداقل سن کامیت‌ها (در میان نوک‌های مرجع، همان‌طور که در بالا گفته شد، هرچند کامیت‌های پایدار حتی در صورتی که توسط یک نگاشت‌بیتی پوشش داده شده باشند همچنان نامزد در نظر گرفته می‌شوند) را که نامزد یک نگاشت‌بیتی شبه‌ادغام پایدار هستند تعیین می‌کند. مقدار پیش‌فرض 1.month.ago است.

تنظیم این آستانه روی مقداری کوچک‌تر (مثلاً 1.week.ago) باعث می‌شود گروه‌های پایدار بیشتری ایجاد شوند (که هزینه تولید یک‌باره را تحمیل می‌کنند) اما این گروه‌ها احتمالاً با گذشت زمان کهنه می‌شوند. استفاده از یک مقدار بزرگ‌تر جریمه معکوس را به همراه دارد (گروه‌های پایدار کمتر که مفیدتر هستند).

bitmapPseudoMerge.<name>.stableSize

اندازه (بر حسب تعداد کامیت‌ها) یک نگاشت‌بیتی شبه‌ادغام پایدار را تعیین می‌کند. مقدار پیش‌فرض 512 است.

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

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

blame.markUnblamableLines

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

blame.markIgnoredLines

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

branch.autoSetupMerge

به git branch، git switch و git checkout می‌گوید شاخه‌های جدید را طوری تنظیم کنند که git-pull(1) به طور مناسب از شاخه نقطه شروع ادغام شود. توجه داشته باشید که حتی اگر این گزینه تنظیم نشده باشد، این رفتار را می‌توان برای هر شاخه با استفاده از گزینه‌های --track و --no-track انتخاب کرد. این گزینه به طور پیش‌فرض روی true است. تنظیمات معتبر عبارتند از:

false

هیچ راه‌اندازی خودکاری انجام نمی‌شود

true

راه‌اندازی خودکار زمانی انجام می‌شود که نقطه شروع یک شاخه ردیابی ریموت باشد

always

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

inherit

اگر نقطه شروع دارای پیکربندی ردیابی باشد، به شاخه جدید کپی می‌شود

simple

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

branch.autoSetupRebase

هنگامی که یک شاخه جدید با git branch، git switch یا git checkout ایجاد می‌شود که شاخه دیگری را ردیابی می‌کند، این متغیر به Git می‌گوید pull را طوری تنظیم کند که به جای ادغام (merge)، بازسازی (rebase) انجام دهد (به branch.<name>.rebase مراجعه کنید). تنظیمات معتبر عبارتند از:

never

rebase هرگز به طور خودکار روی true تنظیم نمی‌شود.

local

rebase برای شاخه‌های ردیابی‌شده سایر شاخه‌های محلی روی true تنظیم می‌شود.

remote

rebase برای شاخه‌های ردیابی‌شده شاخه‌های ردیابی ریموت روی true تنظیم می‌شود.

always

rebase برای همه شاخه‌های ردیابی روی true تنظیم خواهد شد.

برای جزئیات بیشتر در مورد نحوه تنظیم یک شاخه برای ردیابی شاخه دیگر، branch.autoSetupMerge را ببینید. این گزینه به طور پیش‌فرض روی never است.

branch.sort

این متغیر ترتیب مرتب‌سازی شاخه‌ها را هنگام نمایش توسط git-branch(1) کنترل می‌کند. بدون ارائه گزینه --sort=<value>، مقدار این متغیر به عنوان پیش‌فرض استفاده خواهد شد. برای مقادیر معتبر، نام فیلدهای git-for-each-ref(1) را ببینید.

branch.<name>.remote

هنگامی که در شاخه <name> هستید، به git fetch و git push می‌گوید از کدام ریموت واکشی کرده یا به کدام ارسال کنند. ریموت مقصد ارسال ممکن است با remote.pushDefault (برای همه شاخه‌ها) بازنویسی شود. ریموت مقصد ارسال، برای شاخه فعلی، ممکن است بیشتر توسط branch.<name>.pushRemote بازنویسی گردد. اگر هیچ ریموتی پیکربندی نشده باشد، یا اگر در هیچ شاخه‌ای نباشید و بیش از یک ریموت در مخزن تعریف شده باشد، مقدار پیش‌فرض برای واکشی origin و برای ارسال remote.pushDefault است. علاوه بر این، . (یک نقطه) نشان‌دهنده مخزن محلی فعلی است (یک مخزن نقطه‌ای یا dot-repository)، یادداشت نهایی branch.<name>.merge را در زیر ببینید.

branch.<name>.pushRemote

هنگامی که در شاخه <name> هستید، branch.<name>.remote را برای ارسال (push) بازنویسی می‌کند. همچنین remote.pushDefault را برای ارسال از شاخه <name> بازنویسی می‌نماید. هنگامی که از یک مکان (مثلاً بالادست خود) pull می‌کنید و به مکان دیگری (مثلاً مخزن انتشار اختصاصی خود) push انجام می‌دهید، ممکن است بخواهید remote.pushDefault را برای مشخص کردن ریموت مقصد ارسال برای همه شاخه‌ها تنظیم کنید و از این گزینه برای بازنویسی آن برای یک شاخه خاص استفاده نمایید.

branch.<name>.merge

به همراه branch.<name>.remote، شاخه بالادست را برای شاخه داده‌شده تعریف می‌کند. به git fetch/git pull/git rebase می‌گوید کدام شاخه را ادغام کنند و همچنین می‌تواند بر git push تأثیر بگذارد (به push.default مراجعه کنید). هنگامی که در شاخه <name> هستید، به git fetch مشخصه مرجع (refspec) پیش‌فرضی را که باید برای ادغام در FETCH_HEAD علامت‌گذاری شود می‌گوید. مقدار مانند بخش ریموت یک مشخصه مرجع مدیریت می‌شود و باید با مرجعی مطابقت داشته باشد که از ریموت ارائه‌شده توسط branch.<name>.remote واکشی شده است. اطلاعات ادغام توسط git pull (که ابتدا git fetch را فراخوانی می‌کند) برای یافتن شاخه پیش‌فرض ادغام استفاده می‌شود. بدون این گزینه، git pull به طور پیش‌فرض اولین مشخصه مرجع واکشی‌شده را ادغام می‌کند. مقادیر متعددی را برای دستیابی به یک ادغام هشت‌پا (octopus merge) مشخص کنید. اگر می‌خواهید git pull را طوری تنظیم کنید که از شاخه دیگری در مخزن محلی در <name> ادغام شود، می‌توانید branch.<name>.merge را به شاخه مورد نظر اشاره دهید و از تنظیم مسیر نسبی . (یک نقطه) برای branch.<name>.remote استفاده نمایید.

branch.<name>.mergeOptions

گزینه‌های پیش‌فرض را برای ادغام در شاخه <name> تنظیم می‌کند. نحو و گزینه‌های پشتیبانی‌شده مانند گزینه‌های git-merge(1) هستند، اما مقادیر گزینه‌های حاوی نویسه‌های فاصله خالی در حال حاضر پشتیبانی نمی‌شوند.

branch.<name>.rebase

هنگامی که روی true باشد، در زمان اجرای git pull، شاخه <name> را به جای ادغام شاخه پیش‌فرض از ریموت پیش‌فرض، بر روی شاخه واکشی‌شده بازسازی (rebase) می‌کند. برای انجام این کار به شیوه‌ای غیر وابسته به شاخه، pull.rebase را ببینید.

هنگامی که روی merges (یا صرفاً m) باشد، گزینه --rebase-merges را به git rebase ارسال می‌کند تا کامیت‌های ادغام محلی در rebase گنجانده شوند (برای جزئیات به git-rebase(1) مراجعه کنید).

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

توجه: این عملیاتی بالقوه خطرناک است؛ از آن استفاده نکنید مگر اینکه پیامدهای آن را درک کرده باشید (برای جزئیات به git-rebase(1) مراجعه کنید).

branch.<name>.description

توضیحات شاخه، با git branch --edit-description قابل ویرایش است. توضیحات شاخه به طور خودکار به نامه مقدماتی (cover letter) در format-patch یا خلاصه request-pull اضافه می‌شود.

browser.<tool>.cmd

دستور فراخوانی مرورگر مشخص‌شده را تعیین می‌کند. دستور مشخص‌شده در شل ارزیابی شده و نشانی‌های اینترنتی به عنوان آرگومان به آن ارسال می‌شوند. (به git-web--browse(1) مراجعه کنید).

browser.<tool>.path

مسیر ابزار داده‌شده را که ممکن است برای مرور راهنمای HTML (گزینه -w در git-help(1) را ببینید) یا یک مخزن کاری در gitweb (به git-instaweb(1) مراجعه کنید) استفاده شود، بازنویسی می‌کند.

bundle.*

کلیدهای bundle.* ممکن است در یک فایل فهرست بسته (bundle list) که از طریق گزینه git clone --bundle-uri یافت شده ظاهر شوند. این کلیدها در حال حاضر در صورت قرار گرفتن در فایل پیکربندی مخزن هیچ اثری ندارند، اگرچه این موضوع در آینده تغییر خواهد کرد. برای جزئیات بیشتر به the bundle URI design document[1] مراجعه کنید.

bundle.version

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

bundle.mode

این مقدار رشته‌ای باید all یا any باشد. این مقدار مشخص می‌کند که آیا تمام بسته‌های اعلان‌شده برای باز کردن بسته و دستیابی به درک کاملی از اطلاعات بسته‌بندی‌شده مورد نیاز هستند (all) یا اینکه هر یک از URIهای بسته فهرست‌شده کافی است (any).

bundle.heuristic

اگر این کلید با مقدار رشته‌ای وجود داشته باشد، فهرست بسته به گونه‌ای طراحی شده است که با دستورات افزایشی git fetch به خوبی کار کند. این اکتشاف (heuristic) نشان می‌دهد که کلیدهای اضافی برای هر بسته در دسترس هستند که به تعیین زیرمجموعه‌ای از بسته‌ها که کلاینت باید دانلود کند کمک می‌نمایند. تنها مقداری که در حال حاضر قابل درک است creationToken می‌باشد.

bundle.<id>.*

کلیدهای bundle.<id>.* برای توصیف یک آیتم منفرد در فهرست بسته استفاده می‌شوند که برای اهداف شناسایی تحت <id> گروه‌بندی شده‌اند.

bundle.<id>.uri

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

checkout.defaultRemote

هنگامی که شما git checkout <something> یا git switch <something> را اجرا می‌کنید و فقط یک ریموت دارید، ممکن است به طور ضمنی به تحویل گرفتن و ردیابی به عنوان مثال origin/<something> بازگردد. به محض اینکه بیش از یک ریموت با مرجع <something> داشته باشید، این عملکرد متوقف می‌شود. این تنظیم اجازه می‌دهد نام یک ریموت ترجیحی تنظیم شود که همیشه هنگام رفع ابهام اولویت داشته باشد. کاربرد معمول این است که این گزینه روی origin تنظیم شود.

در حال حاضر این متغیر توسط git-switch(1) و git-checkout(1) زمانی استفاده می‌شود که git checkout <something> یا git switch <something> شاخه <something> را روی ریموت دیگری تحویل بگیرند، و همچنین توسط git-worktree(1) زمانی که git worktree add به یک شاخه ریموت ارجاع می‌دهد. این تنظیم ممکن است در آینده برای سایر دستورات یا قابلیت‌های مشابه checkout نیز استفاده شود.

checkout.guess

مقدار پیش‌فرض را برای گزینه --guess یا --no-guess در git checkout و git switch فراهم می‌کند. git-switch(1) و git-checkout(1) را ببینید.

checkout.workers

تعداد کارگرهای موازی (parallel workers) مورد استفاده هنگام به‌روزرسانی درخت کاری. مقدار پیش‌فرض یک است، یعنی اجرای متوالی. اگر روی مقداری کمتر از یک تنظیم شود، Git به تعداد هسته‌های منطقی در دسترس از کارگرها استفاده خواهد کرد. این تنظیم و checkout.thresholdForParallelism بر تمام دستوراتی که عمل چک‌اوت را انجام می‌دهند تأثیر می‌گذارند؛ مانند checkout، clone، reset، sparse-checkout و غیره.

یادداشت
چک‌اوت موازی معمولاً برای مخازن قرارگرفته روی SSD یا روی NFS عملکرد بهتری ارائه می‌دهد. برای مخازن روی دیسک‌های چرخان یا ماشین‌هایی با تعداد هسته‌های اندک، چک‌اوت متوالی پیش‌فرض اغلب عملکرد بهتری دارد. اندازه و سطح فشرده‌سازی یک مخزن نیز ممکن است بر میزان کارایی نسخه موازی تأثیر بگذارد.

checkout.thresholdForParallelism

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

clean.requireForce

یک مقدار بولی برای اینکه git-clean از حذف فایل‌ها خودداری کند مگر آنکه گزینه -f مشخص شده باشد. به‌طور پیش‌فرض true است.

clone.defaultRemoteName

نام ریموتی که هنگام کلون کردن یک مخزن ایجاد می‌شود. مقدار پیش‌فرض origin است. می‌توان آن را با ارسال گزینه خط فرمان --origin به git-clone(1) بازنویسی کرد.

clone.rejectShallow

رد کردن کلون یک مخزن در صورتی که کم‌عمق (shallow) باشد؛ این رفتار را می‌توان با ارسال گزینه --reject-shallow در خط فرمان لغو کرد. به git-clone(1) مراجعه کنید.

clone.filterSubmodules

اگر یک فیلتر کلون جزئی ارائه شده باشد (به --filter در git-rev-list(1) مراجعه کنید) و --recurse-submodules استفاده شود، فیلتر را برای زیرماژول‌ها نیز اعمال می‌کند.

color.advice

یک مقدار بولی برای فعال/غیرفعال کردن رنگ در پیام‌های راهنما (مثلاً هنگامی که یک push ناموفق بود، برای مشاهده فهرست به advice.* مراجعه کنید). ممکن است روی always، false (یا never) یا auto (یا true) تنظیم شود، که در این حالت رنگ‌ها تنها زمانی استفاده می‌شوند که خروجی خطا به یک ترمینال ارسال شود. اگر تنظیم نشده باشد، مقدار color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

color.advice.hint

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

color.blame.highlightRecent

تعیین رنگ حاشیه‌نویسی خطوط برای git blame --color-by-age بسته به قدمت خط.

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

به جای برچسب زمانی مطلق، برچسب‌های زمانی نسبی نیز کار می‌کنند، مثلاً 2.weeks.ago برای اشاره به هر موردی قدیمی‌تر از ۲ هفته معتبر است.

مقدار پیش‌فرض آن blue,12 month ago,white,1 month ago,red است، که هر چیزی قدیمی‌تر از یک سال را آبی می‌کند، تغییرات اخیر بین یک ماه تا یک سال سفید نگه داشته می‌شوند، و خطوط ایجادشده در طول یک ماه گذشته به رنگ قرمز درمی‌آیند.

color.blame.repeatedLines

استفاده از رنگ مشخص‌شده برای رنگ‌آمیزی حاشیه‌نویسی خطوط در git blame --color-lines، در صورتی که از همان کامیت خط قبلی آمده باشند. مقدار پیش‌فرض cyan است.

color.branch

یک مقدار بولی برای فعال/غیرفعال کردن رنگ در خروجی git-branch(1). می‌تواند روی always، false (یا never) یا auto (یا true) تنظیم شود، که در این حالت رنگ‌ها تنها زمانی استفاده می‌شوند که خروجی به یک ترمینال ارسال شود. در صورت تنظیم نشدن، مقدار color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

color.branch.<slot>

استفاده از رنگ سفارشی برای رنگ‌آمیزی شاخه. <slot> یکی از موارد زیر است: current (شاخه فعلی)، local (یک شاخه محلی)، remote (یک شاخه ردیابی از راه دور در refs/remotes/)، upstream (شاخه ردیابی بالادست)، plain (سایر ارجاع‌ها).

color.diff

آیا از دنباله‌های گریز ANSI برای افزودن رنگ به پچ‌ها استفاده شود یا خیر. اگر این مقدار روی always تنظیم شود، دستورات git-diff(1)، git-log(1) و git-show(1) برای تمام پچ‌ها از رنگ استفاده خواهند کرد. اگر روی true یا auto تنظیم شود، این دستورات تنها زمانی که خروجی به ترمینال می‌رود از رنگ استفاده می‌کنند. اگر تنظیم نشده باشد، مقدار color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

این تنظیم روی git-format-patch(1) یا دستورات لوله‌کشی (plumbing) git-diff-* تأثیری ندارد. می‌تواند در خط فرمان با گزینه --color[=<when>] لغو شود.

color.diff.<slot>

استفاده از رنگ سفارشی برای رنگ‌آمیزی diff. <slot> مشخص می‌کند که کدام بخش از پچ از رنگ مشخص‌شده استفاده کند، و یکی از موارد زیر است: context (متن زمینه - plain یک مترادف قدیمی است)، meta (اطلاعات متا)، frag (هدر تکه تغییرات)، func (تابع در هدر تکه تغییرات)، old (خطوط حذف‌شده)، new (خطوط اضافه‌شده)، commit (هدرهای کامیت)، whitespace (برجسته‌سازی خطاهای فاصله‌گذاری)، oldMoved (خطوط حذف‌شده)، newMoved (خطوط اضافه‌شده)، oldMovedDimmed، oldMovedAlternative، oldMovedAlternativeDimmed، newMovedDimmed، newMovedAlternative newMovedAlternativeDimmed (برای جزئیات به تنظیم <mode> در گزینه --color-moved از git-diff(1) مراجعه کنید)، contextDimmed، oldDimmed، newDimmed، contextBold، oldBold و newBold (برای جزئیات به git-range-diff(1) مراجعه کنید).

color.decorate.<slot>

استفاده از رنگ سفارشی برای خروجی git log --decorate. <slot> به ترتیب یکی از مقادیر branch، remoteBranch، tag، stash یا HEAD برای شاخه‌های محلی، شاخه‌های ردیابی ریموت، برچسب‌ها، استش و HEAD است و grafted برای کامیت‌های پیوندخورده (grafted).

color.grep

هنگامی که روی always تنظیم شود، همیشه موارد منطبق را برجسته می‌کند. هنگامی که false (یا never) باشد، هرگز. هنگامی که روی true یا auto تنظیم شود، رنگ را تنها زمانی استفاده می‌کند که خروجی در ترمینال نوشته شود. اگر تنظیم نشده باشد، مقدار color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

color.grep.<slot>

استفاده از رنگ سفارشی برای رنگ‌آمیزی grep. <slot> مشخص می‌کند کدام بخش از خط از رنگ مشخص‌شده استفاده کند، و یکی از موارد زیر است:

context

متن غیرمنطبق در خطوط زمینه (هنگام استفاده از -A، -B یا -C)

filename

پیشوند نام فایل (هنگامی که از -h استفاده نمی‌شود)

function

خطوط نام تابع (هنگام استفاده از -p)

lineNumber

پیشوند شماره خط (هنگام استفاده از -n)

column

پیشوند شماره ستون (هنگام استفاده از --column)

match

متن منطبق (مشابه تنظیم matchContext و matchSelected)

matchContext

متن منطبق در خطوط زمینه

matchSelected

متن منطبق در خطوط انتخاب‌شده. همچنین برای سفارشی‌سازی زیردستورهای زیر از git-log(1) استفاده می‌شود: --grep، --author و --committer.

selected

متن غیرمنطبق در خطوط انتخاب‌شده. همچنین برای سفارشی‌سازی زیردستورهای زیر از git-log(1) استفاده می‌شود: --grep، --author و --committer.

separator

جداکننده‌های بین فیلدها در یک خط (:، - و =) و بین تکه‌ها (--)

color.interactive

هنگامی که روی always تنظیم شود، همیشه از رنگ‌ها برای اعلانات و نمایش‌های تعاملی استفاده کن (مانند مواردی که توسط "git-add --interactive" و "git-clean --interactive" استفاده می‌شود). هنگامی که false (یا never) باشد، هرگز. هنگامی که روی true یا auto تنظیم شود، رنگ‌ها تنها زمانی استفاده می‌شوند که خروجی به ترمینال باشد. در صورت تنظیم نشدن، مقدار color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

color.interactive.<slot>

استفاده از رنگ سفارشی برای خروجی‌های git add --interactive و git clean --interactive. <slot> می‌تواند prompt، header، help یا error برای چهار نوع متمایز از خروجی‌های عادی دستورات تعاملی باشد.

color.pager

یک مقدار بولی برای مشخص کردن اینکه آیا حالت‌های رنگی auto باید خروجی ارسال‌شده به صفحه‌بندی‌کننده (pager) را رنگ‌آمیزی کنند یا خیر. پیش‌فرض true است؛ اگر صفحه‌بندی‌کننده شما کدهای رنگی ANSI را درک نمی‌کند، این را روی false تنظیم کنید.

color.push

یک مقدار بولی برای فعال/غیرفعال کردن رنگ در خطاهای push. ممکن است روی always، false (یا never) یا auto (یا true) تنظیم شود، که در این حالت رنگ‌ها تنها زمانی استفاده می‌شوند که خروجی خطا به یک ترمینال ارسال شود. در صورت تنظیم نشدن، مقدار color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

color.push.error

استفاده از رنگ سفارشی برای خطاهای push.

color.remote

در صورت تنظیم، کلمات کلیدی در ابتدای خط برجسته می‌شوند. این کلمات کلیدی شامل "error" ،"warning" ،"hint" و "success" هستند و بدون حساسیت به بزرگی و کوچکی حروف تطبیق داده می‌شوند. ممکن است روی always، false (یا never) یا auto (یا true) تنظیم شود. در صورت تنظیم نشدن، مقدار color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

color.remote.<slot>

استفاده از رنگ سفارشی برای هر کلمه کلیدی ریموت. <slot> می‌تواند hint، warning، success یا error باشد که با کلمه کلیدی متناظر تطبیق می‌یابد.

color.showBranch

یک مقدار بولی برای فعال/غیرفعال کردن رنگ در خروجی git-show-branch(1). می‌تواند روی always، false (یا never) یا auto (یا true) تنظیم شود، که در این صورت رنگ‌ها تنها زمانی که خروجی به ترمینال ارسال می‌شود به کار می‌روند. در صورت تنظیم نشدن، مقدار color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

color.status

یک مقدار بولی برای فعال/غیرفعال کردن رنگ در خروجی git-status(1). می‌تواند روی always، false (یا never) یا auto (یا true) تنظیم شود، که در این حالت رنگ‌ها فقط زمانی که خروجی به یک ترمینال می‌رود استفاده می‌شوند. در صورت تنظیم نشدن، مقدار color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

color.status.<slot>

استفاده از رنگ سفارشی برای رنگ‌آمیزی وضعیت. <slot> یکی از موارد زیر است: header (متن هدر پیام وضعیت)، added یا updated (فایل‌هایی که اضافه شده‌اند اما هنوز کامیت نشده‌اند)، changed (فایل‌هایی که تغییر یافته‌اند اما در ایندکس اضافه نشده‌اند)، untracked (فایل‌هایی که توسط Git ردیابی نمی‌شوند)، branch (شاخه فعلی)، nobranch (رنگی که هشدار no branch با آن نشان داده می‌شود، با پیش‌فرض قرمز)، localBranch یا remoteBranch (به ترتیب نام شاخه محلی و ریموت، زمانی که اطلاعات شاخه و ردیابی در قالب کوتاه وضعیت نمایش داده می‌شود)، یا unmerged (فایل‌هایی که تغییرات ادغام‌نشده دارند).

color.transport

یک مقدار بولی برای فعال/غیرفعال کردن رنگ هنگام رد شدن pushها. ممکن است روی always، false (یا never) یا auto (یا true) تنظیم شود، که در این حالت رنگ‌ها فقط زمانی که خروجی خطا به یک ترمینال ارسال می‌شود استفاده می‌گردند. در صورت تنظیم نشدن، مقدار color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

color.transport.rejected

استفاده از رنگ سفارشی هنگامی که یک push رد شده باشد.

color.ui

این متغیر مقدار پیش‌فرض را برای متغیرهایی مانند color.diff و color.grep تعیین می‌کند که استفاده از رنگ را در هر خانواده دستور کنترل می‌نمایند. دامنه آن با پشتیبانی دستورات بیشتر از قابلیت پیکربندی جهت تعیین پیش‌فرض برای گزینه --color گسترش خواهد یافت. اگر ترجیح می‌دهید دستورات Git از رنگ استفاده نکنند مگر اینکه صریحاً با پیکربندی دیگری یا گزینه --color فعال شده باشد، آن را روی false یا never تنظیم کنید. اگر می‌خواهید تمام خروجی‌هایی که برای پردازش ماشینی در نظر گرفته نشده‌اند از رنگ استفاده کنند آن را روی always، و اگر می‌خواهید این خروجی‌ها هنگام ارسال به ترمینال از رنگ استفاده کنند آن را روی true یا auto تنظیم نمایید (این گزینه از Git 1.8.4 مقدار پیش‌فرض است).

column.ui

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

این گزینه‌ها زمان فعال بودن این ویژگی را کنترل می‌کنند (به‌طور پیش‌فرض never):

always

همیشه در ستون‌ها نمایش داده شود

never

هرگز در ستون‌ها نمایش داده نشود

auto

اگر خروجی به ترمینال برود در ستون‌ها نمایش داده شود

این گزینه‌ها چیدمان را کنترل می‌کنند (به‌طور پیش‌فرض column). تنظیم هر یک از این موارد در صورتی که هیچ‌یک از مقادیر always، never یا auto مشخص نشده باشند، به معنای always خواهد بود.

column

ستون‌ها قبل از سطرها پر شوند

row

سطرها قبل از ستون‌ها پر شوند

plain

در یک ستون نمایش داده شود

در نهایت، این گزینه‌ها را می‌توان با یک گزینه چیدمان ترکیب کرد (به‌طور پیش‌فرض nodense):

dense

ایجاد ستون‌هایی با اندازه نابرابر برای بهره‌گیری از فضای بیشتر

nodense

ایجاد ستون‌هایی با اندازه برابر

column.branch

مشخص می‌کند که آیا خروجی فهرست شاخه‌ها در git branch به صورت ستونی نمایش داده شود یا خیر. برای جزئیات به column.ui مراجعه کنید.

column.clean

تعیین چیدمان هنگام فهرست کردن موارد در git clean -i، که همیشه فایل‌ها و پوشه‌ها را در ستون‌ها نشان می‌دهد. برای جزئیات به column.ui مراجعه کنید.

column.status

مشخص می‌کند که آیا فایل‌های ردیابی‌نشده در git status به صورت ستونی نمایش داده شوند یا خیر. برای جزئیات به column.ui مراجعه کنید.

column.tag

مشخص می‌کند که آیا فهرست برچسب‌ها در git tag به صورت ستونی نمایش داده شود یا خیر. برای جزئیات به column.ui مراجعه کنید.

commit.cleanup

این تنظیم پیش‌فرض گزینه --cleanup را در git commit بازنویسی می‌کند. برای جزئیات به git-commit(1) مراجعه کنید. تغییر مقدار پیش‌فرض زمانی مفید است که می‌خواهید خطوطی را که با نویسه توضیح (core.commentChar، پیش‌فرض #) شروع می‌شوند همیشه در پیام گزارش خود نگه دارید، که در این حالت دستور زیر را اجرا می‌کنید: git config commit.cleanup whitespace (توجه داشته باشید که اگر این کار را انجام دهید، خودتان باید خطوط راهنما را که با نویسه توضیح در الگوی گزارش کامیت شروع می‌شوند، حذف کنید).

commit.gpgSign

یک مقدار بولی برای مشخص کردن اینکه آیا تمام کامیت‌ها باید با GPG امضا شوند یا خیر. استفاده از این گزینه هنگام انجام عملیاتی مانند rebase می‌تواند به امضا شدن تعداد زیادی کامیت منجر شود. برای جلوگیری از تایپ چندباره عبارت عبور GPG، ممکن است استفاده از یک agent مناسب باشد.

commit.status

یک مقدار بولی برای فعال/غیرفعال کردن درج اطلاعات وضعیت در الگوی پیام کامیت هنگام استفاده از ویرایشگر برای آماده‌سازی پیام کامیت. به‌طور پیش‌فرض true است.

commit.template

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

commit.verbose

یک مقدار بولی یا عددی برای تعیین سطح جزئیات خروجی در git commit. برای جزئیات به git-commit(1) مراجعه کنید.

commitGraph.generationVersion

نوع نسخه شماره نسل را برای استفاده هنگام نوشتن یا خواندن فایل commit-graph مشخص می‌کند. اگر نسخه 1 مشخص شود، تاریخ‌های تصحیح‌شده کامیت نوشته یا خوانده نخواهند شد. به‌طور پیش‌فرض 2 است.

commitGraph.maxNewFilters

مقدار پیش‌فرض را برای گزینه --max-new-filters در دستور git commit-graph write مشخص می‌کند (قیاس کنید با git-commit-graph(1)).

commitGraph.changedPaths

اگر true باشد، git commit-graph write به‌طور پیش‌فرض فیلترهای بلوم مسیرهای تغییریافته را محاسبه کرده و می‌نویسد، که معادل با ارسال --changed-paths است. اگر false یا تنظیم‌نشده باشد، فیلترهای بلوم مسیرهای تغییریافته در حین git commit-graph write فقط در صورتی نوشته می‌شوند که این فیلترها از قبل در فایل commit-graph فعلی وجود داشته باشند. این با رفتار پیش‌فرض git commit-graph write بدون هیچ گزینه --[no-]changed-paths مطابقت دارد. برای بازنویسی فایل commit-graph بدون فیلترها، از گزینه --no-changed-paths استفاده کنید. گزینه خط فرمان --[no-]changed-paths همیشه بر این پیکربندی اولویت دارد. مقدار پیش‌فرض تنظیم‌نشده است.

commitGraph.readChangedPaths

منسوخ شده است. معادل commitGraph.changedPathsVersion=-1 در صورت true بودن، و commitGraph.changedPathsVersion=0 در صورت false بودن است. (اگر commitGraph.changedPathVersion نیز تنظیم شده باشد، commitGraph.changedPathsVersion اولویت دارد.)

commitGraph.changedPathsVersion

نسخه فیلترهای بلوم مسیرهای تغییریافته را که Git می‌خواند و می‌نویسد مشخص می‌کند. ممکن است -1، 0، 1 یا 2 باشد. توجه داشته باشید که مقادیر بزرگتر از 1 ممکن است با نسخه‌های قدیمی‌تر Git که هنوز آن نسخه‌ها را درک نمی‌کنند ناسازگار باشند. هنگام کار در محیطی با نسخه‌های ترکیبی احتیاط کنید.

پیش‌فرض -1 است.

اگر -1 باشد، Git از نسخه فیلترهای بلوم مسیرهای تغییریافته موجود در مخزن استفاده می‌کند، و اگر هیچ‌کدام وجود نداشته باشد پیش‌فرض 1 خواهد بود.

اگر 0 باشد، Git هیچ فیلتر بلومی را نمی‌خواند، و هنگام صدور دستور نوشتن، فیلترهای بلوم نسخه 1 را می‌نویسد.

اگر 1 باشد، Git فقط فیلترهای بلوم نسخه 1 را می‌خواند، و فیلترهای بلوم نسخه 1 را می‌نویسد.

اگر 2 باشد، Git فقط فیلترهای بلوم نسخه 2 را می‌خواند، و فیلترهای بلوم نسخه 2 را می‌نویسد.

برای اطلاعات بیشتر به git-commit-graph(1) مراجعه کنید.

completion.commands

این متغیر تنها توسط git-completion.bash برای افزودن یا حذف دستورات از فهرست دستورات تکمیل خودکار استفاده می‌شود. معمولاً فقط دستورات سطوح بالا (porcelain) و تعداد معدودی دستور منتخب دیگر تکمیل می‌شوند. می‌توانید دستورات بیشتری را که با فاصله از هم جدا شده‌اند به این متغیر اضافه کنید. قرار دادن پیشوند - پیش از دستور، آن را از فهرست موجود حذف می‌کند.

core.fileMode

به Git می‌گوید که آیا بیت اجرایی (executable bit) فایل‌ها در درخت کاری رعایت شود یا خیر.

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

با این حال، ممکن است یک مخزن روی سیستم فایلی باشد که حالت فایل را به درستی مدیریت می‌کند، و این متغیر هنگام ایجاد روی true تنظیم شده باشد، اما بعداً از محیط دیگری در دسترس قرار گیرد که حالت فایل را از بین می‌برد (مانند صادر کردن ext4 از طریق مانت CIFS، یا بازدید از مخزن ایجادشده در Cygwin توسط Git for Windows یا Eclipse). در چنین حالتی ممکن است لازم باشد این متغیر روی false تنظیم شود. به git-update-index(1) مراجعه کنید.

مقدار پیش‌فرض true است (زمانی که core.filemode در فایل پیکربندی مشخص نشده باشد).

core.hideDotFiles

(فقط ویندوز) اگر true باشد، پوشه‌ها و فایل‌های تازه‌ایجادشده را که نام آن‌ها با نقطه آغاز می‌شود به عنوان پنهان علامت‌گذاری می‌کند. اگر dotGitOnly باشد، تنها پوشه .git/ پنهان می‌شود، اما فایل‌های دیگر که با نقطه شروع می‌شوند پنهان نخواهند شد. حالت پیش‌فرض dotGitOnly است.

core.ignoreCase

متغیر داخلی که راهکارهای مختلفی را برای کارکرد بهتر Git در سیستم‌های فایلی که به بزرگی و کوچکی حروف حساس نیستند (مانند APFS، HFS+، FAT، NTFS و غیره) فعال می‌کند. برای مثال، اگر فهرست یک پوشه شامل "makefile" باشد در حالی که Git انتظار "Makefile" را دارد، Git فرض می‌کند که واقعاً همان فایل است و همچنان آن را به عنوان "Makefile" به یاد می‌سپارد.

پیش‌فرض false است، به جز اینکه git-clone(1) یا git-init(1) هنگام ایجاد مخزن، سیستم را بررسی کرده و در صورت لزوم core.ignoreCase را روی true تنظیم می‌کنند.

عملکرد صحیح Git به پیکربندی درست این متغیر متناسب با سیستم عامل و سیستم فایل شما وابسته است. تغییر این مقدار ممکن است رفتارهای غیرمنتظره‌ای ایجاد کند.

core.precomposeUnicode

این گزینه تنها توسط پیاده‌سازی Mac OS از Git استفاده می‌شود. هنگامی که core.precomposeUnicode=true باشد، Git تجزیه یونیکد (unicode decomposition) نام فایل‌ها را که توسط Mac OS انجام شده به حالت اولیه بازمی‌گرداند. این قابلیت هنگام اشتراک‌گذاری یک مخزن میان Mac OS و لینوکس یا ویندوز مفید است. (Git for Windows نسخه 1.7.10 یا بالاتر مورد نیاز است، یا Git تحت cygwin 1.7). هنگامی که false باشد، نام فایل‌ها توسط Git به صورت کاملاً شفاف پردازش می‌شوند که با نسخه‌های قدیمی‌تر Git سازگار است.

core.protectHFS

اگر روی true تنظیم شود، اجازه چک‌اوت مسیرهایی را که در سیستم فایل HFS+ معادل .git محسوب می‌شوند نمی‌دهد. به‌طور پیش‌فرض روی Mac OS برابر true و در سایر جاها false است.

core.protectNTFS

اگر روی true تنظیم شود، اجازه چک‌اوت مسیرهایی را که ممکن است در سیستم فایل NTFS مشکلاتی ایجاد کنند (مانند تداخل با نام‌های "کوتاه" 8.3) نمی‌دهد. به‌طور پیش‌فرض در ویندوز برابر true و در سایر جاها false است.

core.fsmonitor

اگر روی true تنظیم شود، دیمن پایشگر داخلی سیستم فایل را برای این درخت کاری فعال می‌کند (git-fsmonitor--daemon(1)).

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

پایشگر داخلی سیستم فایل در حال حاضر فقط روی پلتفرم‌های پشتیبانی‌شده محدودی در دسترس است. در حال حاضر این پلتفرم‌ها شامل Windows و MacOS هستند.

در غیر این صورت، این متغیر شامل مسیر دستور هوک "fsmonitor" است.

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

به بخش "fsmonitor-watchman" از githooks(5) مراجعه کنید.

توجه داشته باشید که اگر همزمان از چند نسخه Git استفاده می‌کنید (مانند یک نسخه در خط فرمان و نسخه دیگر در یک ابزار IDE)، تعریف core.fsmonitor گسترش یافته تا علاوه بر مسیرهای هوک، مقادیر بولی را نیز بپذیرد. نسخه‌های Git 2.35.1 و قبل از آن، مقادیر بولی را متوجه نمی‌شوند و مقادیر "true" یا "false" را به عنوان مسیر هوکی که باید اجرا شود در نظر می‌گیرند. نسخه‌های Git بین 2.26 تا 2.35.1 به‌طور پیش‌فرض از پروتکل هوک V2 استفاده می‌کنند و به حالت بدون fsmonitor (اسکن کامل) بازمی‌گردند. نسخه‌های Git قبل از 2.26 به‌طور پیش‌فرض از پروتکل هوک V1 استفاده می‌کنند و بدون هشدار فرض می‌کنند هیچ تغییری برای گزارش وجود ندارد (بدون اسکن)، بنابراین دستورات status ممکن است نتایج ناقص گزارش کنند. به همین دلیل، بهتر است پیش از استفاده از پایشگر داخلی سیستم فایل، تمام نسخه‌های Git خود را ارتقا دهید.

core.fsmonitorHookVersion

نسخه پروتکل مورد استفاده هنگام فراخوانی هوک "fsmonitor" را تعیین می‌کند.

در حال حاضر نسخه‌های 1 و 2 وجود دارند. هنگامی که این تنظیم نشده باشد، ابتدا نسخه 2 امتحان می‌شود و اگر با شکست مواجه شد، نسخه 1 امتحان خواهد شد. نسخه 1 از یک برچسب زمانی به عنوان ورودی برای تعیین فایل‌هایی که از آن زمان تغییر کرده‌اند استفاده می‌کند، اما برخی پایشگرها مانند Watchman در صورت استفاده با برچسب زمانی دچار شرایط رقابتی (race conditions) می‌شوند. نسخه 2 از یک رشته مات (opaque string) استفاده می‌کند تا پایشگر بتواند چیزی را بازگرداند که بتوان از آن برای تعیین فایل‌های تغییریافته بدون شرایط رقابتی استفاده کرد.

core.trustctime

اگر false باشد، تفاوت‌های ctime بین ایندکس و درخت کاری نادیده گرفته می‌شوند؛ زمانی مفید است که زمان تغییر inode مرتباً توسط چیزی خارج از Git (خزنده‌های سیستم فایل و برخی سیستم‌های پشتیبان‌گیری) تغییر داده می‌شود. به git-update-index(1) مراجعه کنید. به‌طور پیش‌فرض true است.

core.splitIndex

اگر true باشد، از ویژگی split-index در ایندکس استفاده خواهد شد. به git-update-index(1) مراجعه کنید. به‌طور پیش‌فرض false است.

core.untrackedCache

تعیین می‌کند که با ویژگی حافظه موقت ردیابی‌نشده در ایندکس چه رفتاری شود. اگر این متغیر تنظیم نشده باشد یا روی keep تنظیم گردد، حفظ خواهد شد. اگر روی true تنظیم شود، به‌طور خودکار اضافه خواهد شد. و اگر روی false تنظیم شود، به‌طور خودکار حذف خواهد شد. پیش از تنظیم آن روی true، باید بررسی کنید که mtime در سیستم شما به درستی کار می‌کند. به git-update-index(1) مراجعه کنید. به‌طور پیش‌فرض keep است، مگر اینکه feature.manyFiles فعال باشد که این تنظیم را به‌طور پیش‌فرض روی true قرار می‌دهد.

core.checkStat

هنگامی که وجود نداشته باشد یا روی default تنظیم شده باشد، بسیاری از فیلدهای ساختار stat بررسی می‌شوند تا مشخص شود آیا فایلی از زمان بررسی توسط Git تغییر کرده است یا خیر. هنگامی که این متغیر پیکربندی روی minimal تنظیم شود، بخش زیرثانیه‌ای mtime و ctime، شناسه‌های uid و gid مالک فایل، شماره inode (و شماره دستگاه، در صورتی که Git طوری کامپایل شده باشد که از آن استفاده کند)، از میان این فیلدها از بررسی مستثنی می‌شوند، و تنها بخش ثانیه کامل mtime (و ctime، در صورتی که core.trustCtime تنظیم شده باشد) و اندازه فایل برای بررسی باقی می‌مانند.

پیاده‌سازی‌هایی از Git وجود دارند که مقادیر قابل استفاده‌ای در برخی فیلدها باقی نمی‌گذارند (مانند JGit)؛ با مستثنی کردن این فیلدها از مقایسه، حالت minimal ممکن است به سازگاری متقابل هنگام استفاده همزمان از همان مخزن توسط این سیستم‌های دیگر کمک کند.

core.quotePath

دستوراتی که مسیرها را در خروجی نمایش می‌دهند (مانند ls-files، diff)، نویسه‌های «غیرعادی» را در نام مسیر با قرار دادن مسیر در گیومه دوتایی (double-quotes) و اسکیپ کردن آن نویسه‌ها با بک‌اسلش به همان روشی که C نویسه‌های کنترلی را اسکیپ می‌کند (مانند \t برای TAB، \n برای LF، \\ برای بک‌اسلش) یا بایت‌هایی با مقادیر بزرگتر از 0x80 (مانند هشت‌هشتی \302\265 برای "micro" در UTF-8) نقل‌قول می‌کنند. اگر این متغیر روی false تنظیم شود، بایت‌های بالاتر از 0x80 دیگر «غیرعادی» در نظر گرفته نمی‌شوند. گیومه‌ها، بک‌اسلش و نویسه‌های کنترلی صرف‌نظر از مقدار این متغیر همیشه اسکیپ می‌شوند. نویسه فاصله ساده «غیرعادی» تلقی نمی‌شود. بسیاری از دستورات می‌توانند با استفاده از گزینه -z نام مسیرها را کاملاً دست‌نخورده در خروجی نمایش دهند. مقدار پیش‌فرض true است.

core.eol

نوع پایان خط را برای استفاده در درخت کاری جهت فایل‌هایی که به عنوان متن علامت‌گذاری شده‌اند (خواه از طریق تنظیم بودن صفت text، یا داشتن text=auto و تشخیص خودکار محتویات به عنوان متن توسط Git) مشخص می‌کند. گزینه‌ها عبارتند از lf، crlf و native، که از پایان خط بومی پلتفرم استفاده می‌کند. مقدار پیش‌فرض native است. برای اطلاعات بیشتر درباره تبدیل پایان خط به gitattributes(5) مراجعه کنید. توجه داشته باشید که اگر core.autocrlf روی true یا input تنظیم شده باشد، این مقدار نادیده گرفته می‌شود.

core.safecrlf

اگر true باشد، Git بررسی می‌کند که آیا تبدیل CRLF هنگام فعال بودن تبدیل پایان خط برگشت‌پذیر است یا خیر. Git بررسی خواهد کرد که آیا دستوری، فایلی را در درخت کاری چه به طور مستقیم و چه غیرمستقیم تغییر می‌دهد یا خیر. برای مثال، کامیت کردن یک فایل و سپس چک‌اوت کردن همان فایل باید همان فایل اصلی را در درخت کاری ایجاد کند. اگر برای تنظیم فعلی core.autocrlf چنین نباشد، Git فایل را رد خواهد کرد. متغیر می‌تواند روی "warn" تنظیم شود، که در این حالت Git تنها درباره تبدیل برگشت‌ناپذیر هشدار می‌دهد اما عملیات را ادامه خواهد داد.

تبدیل CRLF خطر اندکی برای خراب کردن داده‌ها به همراه دارد. هنگامی که فعال است، Git در حین کامیت CRLF را به LF و در حین چک‌اوت LF را به CRLF تبدیل می‌کند. فایلی که قبل از کامیت حاوی ترکیبی از LF و CRLF باشد، توسط Git قابل بازسازی نیست. برای فایل‌های متنی این کار مناسبی است: پایان خطوط را اصلاح می‌کند تا تنها پایان خطوط LF در مخزن داشته باشیم. اما برای فایل‌های باینری که تصادفاً به عنوان متن طبقه‌بندی شده‌اند، تبدیل می‌تواند داده‌ها را تخریب کند.

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

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

توجه داشته باشید، این بررسی ایمنی بدان معنا نیست که یک چک‌اوت فایلی همسان با فایل اصلی برای یک تنظیم متفاوت از core.eol و core.autocrlf تولید کند، بلکه تنها برای تنظیم فعلی صادق است. برای مثال، یک فایل متنی با LF تحت core.eol=lf پذیرفته می‌شود و ممکن است بعداً با core.eol=crlf چک‌اوت شود، که در این صورت فایل حاصل شامل CRLF خواهد بود، هرچند فایل اصلی شامل LF بوده است. با این حال، در هر دو درخت کاری پایان خطوط یکدست خواهد بود؛ یعنی یا همگی LF یا همگی CRLF، اما هرگز ترکیبی نخواهد بود. فایلی با پایان خطوط مختلط توسط سازوکار core.safecrlf گزارش خواهد شد.

core.autocrlf

تنظیم این متغیر روی "true" همانند تنظیم صفت text روی "auto" برای تمام فایل‌ها و تنظیم core.eol روی "crlf" است. اگر می‌خواهید پایان خطوط CRLF را در دایرکتوری کاری خود داشته باشید در حالی که مخزن دارای پایان خطوط LF است، آن را روی true تنظیم کنید. این متغیر می‌تواند روی input تنظیم شود، که در این حالت هیچ تبدیلی در خروجی صورت نمی‌پذیرد.

core.checkRoundtripEncoding

فهرستی از رمزگذاری‌ها که با کاما یا نویسه فاصله از هم جدا شده‌اند و در صورتی که در صفت working-tree-encoding استفاده شوند (به gitattributes(5) مراجعه کنید)، Git بررسی رفت‌وبرگشت به UTF-8 را روی آن‌ها انجام می‌دهد. مقدار پیش‌فرض SHIFT-JIS است.

core.symlinks

اگر false باشد، پیوندهای نمادین به صورت فایل‌های متنی ساده و کوچکی که شامل متن پیوند هستند چک‌اوت می‌شوند. دستورات git-update-index(1) و git-add(1) نوع ثبت‌شده را به فایل معمولی تغییر نخواهند داد. در سیستم‌های فایلی مانند FAT که از پیوندهای نمادین پشتیبانی نمی‌کنند مفید است.

مقدار پیش‌فرض true است، به جز اینکه git-clone(1) یا git-init(1) هنگام ایجاد مخزن، وضعیت را بررسی کرده و در صورت لزوم core.symlinks را روی false تنظیم می‌کنند.

core.gitProxy

یک «دستور پروکسی» برای اجرا (به صورت command host port) به جای برقراری ارتباط مستقیم با سرور ریموت هنگام استفاده از پروتکل Git برای واکشی (fetch). اگر مقدار متغیر در قالب "COMMAND for DOMAIN" باشد، دستور تنها روی نام‌های میزبانی اعمال می‌شود که به رشته دامنه مشخص‌شده ختم می‌شوند. این متغیر ممکن است چندین بار تنظیم شود و به ترتیب داده‌شده تطبیق داده می‌شود؛ اولین تطابق برنده است.

می‌تواند توسط متغیر محیطی GIT_PROXY_COMMAND (که همیشه به طور سراسری و بدون رفتار خاص "for" اعمال می‌شود) بازنویسی شود.

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

core.sshCommand

اگر این متغیر تنظیم شود، git fetch و git push هنگامی که نیاز به اتصال به یک سیستم ریموت دارند، از دستور مشخص‌شده به جای ssh استفاده خواهند کرد. این دستور در همان قالب متغیر محیطی GIT_SSH_COMMAND است و هنگام تنظیم بودن آن متغیر محیطی، اولویت با متغیر محیطی خواهد بود.

core.ignoreStat

اگر true باشد، Git با تنظیم بیت "assume-unchanged" برای آن دسته از فایل‌های ردیابی‌شده‌ای که آن‌ها را به طور یکسان در هر دو بخش ایندکس و درخت کاری به‌روزرسانی کرده است، از فراخوانی‌های lstat() برای تشخیص اینکه آیا فایل‌ها تغییر کرده‌اند خودداری می‌کند.

هنگامی که فایل‌ها خارج از Git تغییر می‌یابند، کاربر باید فایل‌های تغییریافته را صریحاً استیج کند (مثلاً به بخش Examples در git-update-index(1) مراجعه کنید). Git معمولاً تغییرات این فایل‌ها را تشخیص نخواهد داد.

این امر در سیستم‌هایی که فراخوانی‌های lstat() در آن‌ها بسیار کند است، مانند CIFS/Microsoft Windows مفید است.

به‌طور پیش‌فرض false است.

core.preferSymlinkRefs

به جای قالب پیش‌فرض "symref" برای HEAD و سایر فایل‌های ارجاع نمادین، از پیوندهای نمادین استفاده می‌کند. این قابلیت گاهی برای کار با اسکریپت‌های قدیمی که انتظار دارند HEAD یک پیوند نمادین باشد مورد نیاز است.

این پیکربندی منسوخ شده است و در Git 3.0 حذف خواهد شد. ارجاع‌های نمادین همواره به صورت symref متنی نوشته خواهند شد.

core.alternateRefsCommand

هنگام اعلان نوک‌های تاریخچه در دسترس از یک منبع جایگزین (alternate)، به جای git-for-each-ref(1) از پوسته برای اجرای دستور مشخص‌شده استفاده می‌کند. نخستین آرگومان مسیر مطلق منبع جایگزین است. خروجی باید شامل یک شناسه شیء هگزادسیمال در هر خط باشد (یعنی مشابه آنچه توسط git for-each-ref --format='%(objectname)' تولید می‌شود).

توجه داشته باشید که عموماً نمی‌توانید git for-each-ref را مستقیماً در مقدار پیکربندی قرار دهید، زیرا مسیر مخزن را به عنوان آرگومان نمی‌پذیرد (اما می‌توانید دستور بالا را در یک اسکریپت شل کپسوله‌سازی کنید).

core.alternateRefsPrefixes

هنگام فهرست کردن ارجاع‌ها از یک منبع جایگزین، تنها ارجاع‌هایی را فهرست کن که با پیشوند داده‌شده شروع می‌شوند. پیشوندها همان‌گونه تطبیق داده می‌شوند که گویی به عنوان آرگومان به git-for-each-ref(1) داده شده‌اند. برای فهرست کردن چندین پیشوند، آن‌ها را با فاصله جدا کنید. اگر core.alternateRefsCommand تنظیم شده باشد، تنظیم core.alternateRefsPrefixes هیچ اثری ندارد.

core.bare

اگر true باشد، این مخزن به صورت bare (مخزن فاقد درخت کاری) فرض می‌شود و هیچ دایرکتوری کاری مرتبط با آن وجود ندارد. در این حالت تعدادی از دستوراتی که به دایرکتوری کاری نیاز دارند غیرفعال خواهند شد، مانند git-add(1) یا git-merge(1).

این تنظیم به‌طور خودکار توسط git-clone(1) یا git-init(1) هنگام ایجاد مخزن حدس زده می‌شود. به‌طور پیش‌فرض مخزنی که به "/.git" ختم می‌شود غیر bare فرض می‌شود (bare = false)، در حالی که سایر مخازن به صورت bare فرض می‌شوند (bare = true).

core.worktree

مسیر ریشه درخت کاری را تنظیم می‌کند. اگر متغیر محیطی GIT_COMMON_DIR تنظیم شده باشد، core.worktree نادیده گرفته شده و برای تعیین ریشه درخت کاری استفاده نخواهد شد. این مقدار می‌تواند توسط متغیر محیطی GIT_WORK_TREE و گزینه خط فرمان --work-tree لغو شود. مقدار می‌تواند یک مسیر مطلق یا نسبی نسبت به مسیر پوشه .git باشد، که یا توسط --git-dir یا GIT_DIR مشخص شده، یا به‌طور خودکار شناسایی شده است. اگر --git-dir یا GIT_DIR مشخص شده باشد اما هیچ‌کدام از گزینه‌های --work-tree، GIT_WORK_TREE و core.worktree مشخص نشده باشند، دایرکتوری کاری فعلی به عنوان بالاترین سطح درخت کاری شما در نظر گرفته می‌شود.

توجه داشته باشید که این متغیر حتی زمانی که در یک فایل پیکربندی در یک زیرپوشه ".git" از یک پوشه تنظیم شده باشد و مقدار آن با پوشه اخیر متفاوت باشد (مثلاً "/path/to/.git/config" مقدار core.worktree را روی "/different/path" تنظیم کرده باشد) رعایت می‌شود، که به احتمال زیاد یک پیکربندی نادرست است. اجرای دستورات Git در پوشه "/path/to" همچنان از "/different/path" به عنوان ریشه درخت کاری استفاده خواهد کرد و می‌تواند باعث سردرگمی شود مگر اینکه بدانید چه می‌کنید (مثلاً در حال ایجاد یک تصویر لحظه‌ای فقط‌خواندنی از همان ایندکس در مکانی متفاوت از درخت کاری معمول مخزن هستید).

core.lockfilePid

اگر true باشد، Git یک فایل PID در کنار فایل‌های قفل ایجاد می‌کند. هنگامی که گرفتن قفل با شکست مواجه شود و یک فایل PID وجود داشته باشد، Git می‌تواند اطلاعات تشخیصی بیشتری درباره فرآیندی که قفل را در اختیار دارد ارائه دهد، از جمله اینکه آیا هنوز در حال اجرا است یا خیر. به‌طور پیش‌فرض false است.

فایل PID با درج ~pid قبل از پسوند .lock نام‌گذاری می‌شود. برای مثال، اگر فایل قفل index.lock باشد، فایل PID با نام index~pid.lock خواهد بود. این فایل شامل یک خط به قالب pid <value> به همراه یک سطر تازه است.

core.logAllRefUpdates

فعال‌سازی reflog. به‌روزرسانی‌های یک ارجاع <ref> با الحاق کردن SHA-1 جدید و قدیم، تاریخ/زمان و دلیل به‌روزرسانی در فایل "$GIT_DIR/logs/<ref>" ثبت می‌شوند، اما تنها در صورتی که فایل وجود داشته باشد. اگر این متغیر پیکربندی روی true تنظیم شده باشد، فایل مفقود "$GIT_DIR/logs/<ref>" به‌طور خودکار برای نوک شاخه‌ها (یعنی زیر refs/heads/)، ارجاع‌های ریموت (یعنی زیر refs/remotes/)، ارجاع‌های یادداشت (یعنی زیر refs/notes/) و ارجاع نمادین HEAD ایجاد می‌شود. اگر روی always تنظیم شود، یک reflog مفقود به‌طور خودکار برای هر ارجاعی زیر refs/ ایجاد خواهد شد.

این اطلاعات می‌تواند برای تعیین اینکه چه کامیتی نوک یک شاخه در "2 روز پیش" بوده است استفاده شود.

این مقدار به‌طور پیش‌فرض در مخزنی که دارای درخت کاری مرتبط باشد true، و به‌طور پیش‌فرض در یک مخزن bare برابر false است.

core.repositoryFormatVersion

متغیر داخلی برای شناسایی قالب مخزن و نسخه چیدمان. به gitrepository-layout(5) مراجعه کنید.

core.sharedRepository

هنگامی که روی group (یا true) تنظیم شود، مخزن میان چندین کاربر در یک گروه قابل اشتراک‌گذاری می‌شود (با اطمینان از اینکه تمامی فایل‌ها و اشیاء توسط گروه قابل نوشتن باشند). هنگامی که روی all (یا world یا everybody) تنظیم شود، مخزن علاوه بر اشتراک‌گذاری گروهی، برای همه کاربران قابل خواندن خواهد بود. هنگامی که روی umask (یا false) تنظیم شود، Git از دسترسی‌های گزارش‌شده توسط umask(2) استفاده خواهد کرد. هنگامی که روی 0xxx تنظیم شود، که در آن 0xxx یک عدد هشت‌هشتی (octal) است، فایل‌های درون مخزن دارای این مقدار حالت (mode) دسترسی خواهند بود. 0xxx مقدار umask کاربر را بازنویسی خواهد کرد (در حالی که گزینه‌های دیگر تنها بخش‌های مورد درخواست از مقدار umask کاربر را بازنویسی می‌کنند). مثال‌ها: 0660 مخزن را برای مالک و گروه قابل خواندن/نوشتن می‌کند، اما برای دیگران غیرقابل دسترس می‌سازد (معادل group مگر اینکه umask برای نمونه 0022 باشد). 0640 مخزنی است که برای گروه قابل خواندن است اما برای گروه قابل نوشتن نیست. به git-init(1) مراجعه کنید. به طور پیش‌فرض False است.

core.warnAmbiguousRefs

اگر روی true تنظیم شود، چنانچه نام ref ارسالی شما مبهم باشد و ممکن باشد با چندین ref در مخزن مطابقت داشته باشد، Git به شما هشدار خواهد داد. به طور پیش‌فرض True است.

core.compression

یک عدد صحیح بین -1 تا 9 که سطح فشرده‌سازی پیش‌فرض را مشخص می‌کند. مقدار -1 پیش‌فرض zlib است. مقدار 0 به معنای عدم فشرده‌سازی است، و 1 تا 9 موازنه‌های مختلف میان سرعت/اندازه هستند که 9 کندترین آن‌هاست. در صورت تنظیم، این متغیر مقداری پیش‌فرض را برای سایر متغیرهای فشرده‌سازی فراهم می‌کند، مانند core.looseCompression و pack.compression.

core.looseCompression

یک عدد صحیح بین -1 تا 9 که سطح فشرده‌سازی را برای اشیائی که در یک pack file قرار ندارند مشخص می‌کند. مقدار -1 پیش‌فرض zlib است. مقدار 0 به معنای عدم فشرده‌سازی است، و 1 تا 9 موازنه‌های مختلف میان سرعت/اندازه هستند که 9 کندترین آن‌هاست. اگر تنظیم نشود، به طور پیش‌فرض مقدار core.compression در نظر گرفته می‌شود. اگر آن هم تنظیم نشده باشد، به طور پیش‌فرض 1 (بهترین سرعت) خواهد بود.

core.packedGitWindowSize

تعداد بایت‌های یک pack file برای نگاشت (map) در حافظه در یک عملیات نگاشت منفرد. اندازه‌های بزرگ‌تر پنجره ممکن است به سیستم شما اجازه دهند تعداد کمتری از pack fileهای بزرگ را سریع‌تر پردازش کند. اندازه‌های کوچک‌تر پنجره به دلیل افزایش فراخوانی‌ها به مدیر حافظه سیستم‌عامل، بر کارایی تأثیر منفی خواهند گذاشت، اما ممکن است هنگام دسترسی به تعداد زیادی از pack fileهای بزرگ کارایی را بهبود بخشند.

اگر NO_MMAP در زمان کامپایل تنظیم شده باشد مقدار پیش‌فرض 1 MiB است، در غیر این صورت روی پلتفرم‌های 32 بیتی 32 MiB و روی پلتفرم‌های 64 بیتی 1 GiB است. این مقدار باید برای همه کاربران/سیستم‌های عامل منطقی باشد. احتمالاً نیازی به تغییر این مقدار ندارید.

پسوندهای واحد متداول شامل k، m، یا g پشتیبانی می‌شوند.

core.packedGitLimit

حداکثر تعداد بایت‌ها برای نگاشت همزمان از pack fileها به حافظه. اگر Git برای تکمیل یک عملیات نیاز به دسترسی همزمان به بیش از این مقدار بایت داشته باشد، نواحی موجود را از حالت نگاشت خارج می‌کند (unmap) تا فضای آدرس مجازی را درون فرآیند بازپس گیرد.

پیش‌فرض روی پلتفرم‌های 32 بیتی 256 MiB و روی پلتفرم‌های 64 بیتی 32 TiB (در عمل نامحدود) است. این مقدار باید برای همه کاربران/سیستم‌های عامل به جز در بزرگ‌ترین پروژه‌ها معقول باشد. احتمالاً نیازی به تغییر این مقدار ندارید.

پسوندهای واحد متداول شامل k، m، یا g پشتیبانی می‌شوند.

core.deltaBaseCacheLimit

حداکثر تعداد بایت به ازای هر ریسه (thread) برای رزرو جهت کش کردن اشیاء پایه که ممکن است توسط چندین شیء دلتایی (deltified) مورد ارجاع قرار گیرند. با ذخیره کامل اشیاء پایه از حالت فشرده خارج‌شده در یک کش، Git قادر است از باز کردن و از حالت فشرده خارج کردن چندباره اشیاء پایه پرکاربرد جلوگیری کند.

پیش‌فرض روی تمامی پلتفرم‌ها 96 MiB است. این مقدار باید برای همه کاربران/سیستم‌های عامل به جز در بزرگ‌ترین پروژه‌ها معقول باشد. احتمالاً نیازی به تغییر این مقدار ندارید.

پسوندهای واحد متداول شامل k، m، یا g پشتیبانی می‌شوند.

core.bigFileThreshold

اندازه فایل‌هایی که "بزرگ" در نظر گرفته می‌شوند، که همان‌طور که در ادامه توضیح داده شده رفتار دستورات متعدد گیت و همچنین نحوه ذخیره‌سازی چنین فایل‌هایی را در مخزن تغییر می‌دهد. مقدار پیش‌فرض 512 MiB است. پسوندهای واحد متداول شامل k، m، یا g پشتیبانی می‌شوند.

فایل‌های بالاتر از حد پیکربندی‌شده:

•به صورت فشرده‌شده (deflated) در packfileها بدون تلاش برای فشرده‌سازی دلتا ذخیره می‌شوند.

حد پیش‌فرض اساساً با در نظر گرفتن این کاربرد تنظیم شده است. با این تنظیم، در اکثر پروژه‌ها کد منبع و سایر فایل‌های متنی تحت فشرده‌سازی دلتا قرار می‌گیرند، اما فایل‌های چندرسانه‌ای باینری بزرگ‌تر شامل آن نمی‌شوند.

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

•طوری رفتار خواهد شد که گویی برچسب "binary" دارند (به gitattributes(5) مراجعه کنید). برای نمونه git-log(1) و git-diff(1) برای فایل‌های بالاتر از این حد، دیف محاسبه نخواهند کرد.
•عموماً هنگام نوشتن به صورت جریانی (streamed) منتقل می‌شوند، که از مصرف بیش از حد حافظه با هزینه مقداری سربار ثابت جلوگیری می‌کند. دستوراتی که از این قابلیت استفاده می‌کنند شامل git-archive(1)، git-fast-import(1)، git-index-pack(1)، git-unpack-objects(1) و git-fsck(1) هستند.

core.excludesFile

مسیر فایلی را مشخص می‌کند که علاوه بر .gitignore (به ازای هر دایرکتوری) و .git/info/exclude، حاوی الگوهایی برای توصیف مسیرهایی است که نباید ردگیری شوند. مقدار پیش‌فرض آن $XDG_CONFIG_HOME/git/ignore است. اگر $XDG_CONFIG_HOME تنظیم نشده یا خالی باشد، $HOME/.config/git/ignore به جای آن استفاده می‌شود. به gitignore(5) مراجعه کنید.

core.askPass

به برخی از دستورات (مانند رابط‌های svn و http) که به صورت تعاملی گذرواژه درخواست می‌کنند می‌توان اعلام کرد از یک برنامه خارجی که از طریق مقدار این متغیر مشخص شده است استفاده کنند. این مقدار می‌تواند توسط متغیر محیطی GIT_ASKPASS بازنویسی شود. در صورت عدم تنظیم، به مقدار متغیر محیطی SSH_ASKPASS یا در صورت نبود آن، به یک اعلان ساده گذرواژه برمی‌گردد. به برنامه خارجی باید یک اعلان مناسب به عنوان آرگومان خط فرمان داده شود و گذرواژه را در STDOUT خود بنویسد.

core.attributesFile

مسیر فایلی را مشخص می‌کند که علاوه بر .gitattributes (به ازای هر دایرکتوری) و .git/info/attributes، حاوی مشخصه‌ها (attributes) است (به gitattributes(5) مراجعه کنید). مقدار پیش‌فرض آن $XDG_CONFIG_HOME/git/attributes است. اگر $XDG_CONFIG_HOME تنظیم نشده یا خالی باشد، $HOME/.config/git/attributes به جای آن استفاده می‌شود.

core.hooksPath

به طور پیش‌فرض، Git قلاب‌های شما را در دایرکتوری $GIT_DIR/hooks جستجو می‌کند. این متغیر را روی مسیر متفاوتی تنظیم کنید، برای نمونه /etc/git/hooks، و Git تلاش خواهد کرد قلاب‌های شما را در آن دایرکتوری پیدا کند، برای نمونه /etc/git/hooks/pre-receive به جای $GIT_DIR/hooks/pre-receive.

مسیر می‌تواند مطلق یا نسبی باشد. یک مسیر نسبی، نسبت به دایرکتوری که قلاب‌ها در آن اجرا می‌شوند در نظر گرفته می‌شود (به بخش "DESCRIPTION" در githooks(5) مراجعه کنید).

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

همچنین می‌توانید تمام قلاب‌ها را با تنظیم core.hooksPath روی /dev/null به طور کامل غیرفعال کنید. این کار معمولاً تنها برای کاربران حرفه‌ای و به صورت به ازای هر دستور با استفاده از پارامترهای پیکربندی به فرم git -c core.hooksPath=/dev/null .... توصیه می‌شود.

core.editor

دستوراتی مانند commit و tag که به شما امکان می‌دهند با اجرای یک ویرایشگر پیام‌ها را ویرایش کنید، در صورتی که این متغیر تنظیم شده باشد و متغیر محیطی GIT_EDITOR تنظیم نشده باشد، از مقدار این متغیر استفاده می‌کنند. به git-var(1) مراجعه کنید.

core.commentChar, core.commentString

دستوراتی مانند commit و tag که به شما امکان ویرایش پیام‌ها را می‌دهند، خطی را که با این نویسه آغاز شود به عنوان کامنت در نظر گرفته و پس از بسته شدن ویرایشگر آن‌ها را حذف می‌کنند (پیش‌فرض #).

اگر روی "auto" تنظیم شود، git-commit نویسه‌ای را انتخاب خواهد کرد که نویسه ابتدایی هیچ‌یک از خطوط در پیام‌های کامیت موجود نباشد. پشتیبانی از این مقدار منسوخ شده است و در Git 3.0 به دلیل محدودیت‌های زیر حذف خواهد شد:

•با افزودن کامنت‌ها در یک الگوی پیام کامیت ناسازگار است. این شامل کامنت‌های تعارض که توسط cherry-pick، merge، rebase و revert به پیام کامیت اضافه می‌شوند نیز می‌شود.
•با افزودن کامنت‌ها به پیام کامیت در قلاب prepare-commit-msg ناسازگار است.
•هنگام rebase کردن با دستورات fixup و squash ناسازگار است،
•توسط git notes رعایت نمی‌شود

توجه داشته باشید که این دو متغیر نام‌های مستعار (alias) یکدیگر هستند، و در نسخه‌های مدرن Git آزادید که از یک رشته (برای نمونه // یا ⁑⁕⁑) با commentChar استفاده کنید. نسخه‌های قبل از v2.45.0 گیت متغیر commentString را نادیده می‌گیرند اما مقداری از commentChar را که شامل بیش از یک بایت اسکی باشد رد می‌کنند. اگر قصد دارید از پیکربندی خود هم با نسخه‌های قدیمی‌تر و هم جدیدتر Git استفاده کنید، ممکن است مایل باشید هر دو را مشخص کنید:

[core]
# single character for older versions
commentChar = "#"
# string for newer versions (which will override commentChar
# because it comes later in the file)
commentString = "//"

core.filesRefLockTimeout

مدت زمان به میلی‌ثانیه برای تلاش مجدد هنگام تلاش برای قفل کردن یک ارجاع (ref) منفرد. مقدار 0 به معنای اصلاً تلاش مجدد نکردن است؛ -1 به معنای تلاش نامحدود است. پیش‌فرض 100 است (یعنی تلاش مجدد برای 100 میلی‌ثانیه).

core.packedRefsTimeout

مدت زمان به میلی‌ثانیه برای تلاش مجدد هنگام تلاش برای قفل کردن فایل packed-refs. مقدار 0 به معنای اصلاً تلاش مجدد نکردن است؛ -1 به معنای تلاش نامحدود است. پیش‌فرض 1000 است (یعنی تلاش مجدد برای 1 ثانیه).

core.pager

نمایش‌دهنده متن (pager) برای استفاده توسط دستورات گیت (برای نمونه less). این مقدار برای تفسیر شدن توسط شل در نظر گرفته شده است. ترتیب اولویت عبارت است از متغیر محیطی $GIT_PAGER، سپس پیکربندی core.pager، سپس $PAGER، و سپس پیش‌فرض انتخاب‌شده در زمان کامپایل (معمولاً less).

زمانی که متغیر محیطی LESS تنظیم نشده باشد، Git آن را روی FRX تنظیم می‌کند (اگر متغیر محیطی LESS تنظیم شده باشد، Git اصلاً آن را تغییر نمی‌دهد). اگر می‌خواهید تنظیم پیش‌فرض Git برای LESS را به صورت انتخابی لغو کنید، می‌توانید core.pager را برای نمونه روی less -S تنظیم کنید. این مقدار توسط Git به شل منتقل می‌شود، که دستور نهایی را به LESS=FRX less -S ترجمه خواهد کرد. محیط گزینه S را تنظیم نکرده اما خط فرمان این کار را انجام می‌دهد، که به less دستور می‌دهد خطوط طولانی را کوتاه (truncate) کند. به طور مشابه، تنظیم core.pager روی less -+F گزینه F مشخص‌شده توسط محیط را از طریق خط فرمان غیرفعال می‌کند، که رفتار "خروج در صورت جا شدن در یک صفحه" در less را غیرفعال می‌سازد. می‌توان برخی گزینه‌ها را به طور اختصاصی برای دستورات خاصی فعال کرد: برای مثال، تنظیم pager.blame روی less -S کوتاه‌سازی خطوط را تنها برای git blame فعال می‌سازد.

به همین شکل، زمانی که متغیر محیطی LV تنظیم نشده باشد، Git آن را روی -c تنظیم می‌کند. می‌توانید این تنظیم را با export کردن LV با مقداری دیگر یا با تنظیم core.pager روی lv +c لغو کنید.

core.whitespace

فهرستی جداشده با کاما از مشکلات رایج فاصله خالی (whitespace) برای بررسی و جلب توجه. git diff از color.diff.whitespace برای برجسته‌سازی آن‌ها استفاده می‌کند، و git apply --whitespace=error آن‌ها را به عنوان خطا در نظر می‌گیرد. می‌توانید پیشوند - را برای غیرفعال کردن هر یک از آن‌ها به کار ببرید (برای نمونه -trailing-space):
•blank-at-eol فاصله‌های خالی انتهایی در انتهای خط را به عنوان خطا در نظر می‌گیرد (به طور پیش‌فرض فعال است).
•space-before-tab نویسه فاصله‌ای را که بلافاصله پیش از یک نویسه تب در بخش تورفتگی اولیه خط ظاهر شود به عنوان خطا در نظر می‌گیرد (به طور پیش‌فرض فعال است).
•indent-with-non-tab خطی را که به جای تب‌های معادل با نویسه‌های فاصله تورفته شده باشد به عنوان خطا در نظر می‌گیرد (به طور پیش‌فرض فعال نیست).
•tab-in-indent نویسه تب در بخش تورفتگی اولیه خط را به عنوان خطا در نظر می‌گیرد (به طور پیش‌فرض فعال نیست).
•blank-at-eof خطوط خالی اضافه‌شده در انتهای فایل را به عنوان خطا در نظر می‌گیرد (به طور پیش‌فرض فعال است).
•trailing-space شورت‌کدی برای پوشش دادن هر دو مورد blank-at-eol و blank-at-eof است.
•cr-at-eol بازگشت به ابتدای خط (carriage-return) در انتهای خط را به عنوان بخشی از پایان‌دهنده خط تلقی می‌کند، یعنی با فعال بودن آن، اگر نویسه پیش از چنین carriage-return یک فاصله خالی نباشد، trailing-space فعال نمی‌شود (به طور پیش‌فرض فعال نیست).
•incomplete-line آخرین خط فایلی را که فاقد خط جدید (newline) در انتها است به عنوان خطا در نظر می‌گیرد (به طور پیش‌فرض فعال نیست).
•tabwidth=<n> مشخص می‌کند که یک تب چند موقعیت نویسه را اشغال می‌کند؛ این گزینه برای indent-with-non-tab و زمانی که Git خطاهای tab-in-indent را اصلاح می‌کند کاربرد دارد. عرض پیش‌فرض تب 8 است. مقادیر مجاز از 1 تا 63 می‌باشند.

core.fsync

فهرستی جداشده با کاما از مؤلفه‌های مخزن که باید در زمان ایجاد یا تغییر، از طریق core.fsyncMethod پایدارسازی (hardened) شوند. می‌توانید پایدارسازی هر مؤلفه را با قرار دادن پیشوند - در ابتدای آن غیرفعال کنید. مواردی که پایدارسازی نشده‌اند ممکن است در صورت خاموش شدن غیرعادی سیستم از دست بروند. مگر در مواردی که نیازمندی‌های خاصی داشته باشید، توصیه می‌شود این گزینه را خالی بگذارید یا یکی از موارد committed، added، یا all را انتخاب کنید.

هنگام مواجهه با این پیکربندی، مجموعه مؤلفه‌ها با مقدار پیش‌فرض پلتفرم آغاز می‌شود، مؤلفه‌های غیرفعال حذف می‌شوند، و مؤلفه‌های اضافی افزوده می‌گردند. none وضعیت را بازنشانی می‌کند تا پیش‌فرض پلتفرم نادیده گرفته شود.

رشته خالی پیکربندی fsync را به پیش‌فرض پلتفرم بازنشانی می‌کند. پیش‌فرض در اکثر پلتفرم‌ها معادل core.fsync=committed,-loose-object است، که کارایی خوبی دارد، اما در صورت خاموش شدن غیرعادی سیستم، خطر از دست رفتن کارهای اخیر را به همراه دارد.

•none مجموعه مؤلفه‌های تحت fsync را پاک می‌کند.
•loose-object اشیائی را که در قالب loose-object به مخزن اضافه شده‌اند پایدارسازی می‌کند.
•pack اشیائی را که در قالب packfile به مخزن اضافه شده‌اند پایدارسازی می‌کند.
•pack-metadata بیت‌مپ‌ها و ایندکس‌های packfile را پایدارسازی می‌کند.
•commit-graph فایل commit-graph را پایدارسازی می‌کند.
•index ایندکس را هنگام تغییر پایدارسازی می‌کند.
•objects گزینه‌ای تجمیعی است که معادل loose-object,pack می‌باشد.
•reference ارجاع‌های تغییریافته در مخزن را پایدارسازی می‌کند.
•derived-metadata گزینه‌ای تجمیعی است که معادل pack-metadata,commit-graph می‌باشد.
•committed گزینه‌ای تجمیعی است که در حال حاضر معادل objects است. این حالت مقداری از کارایی را فدا می‌کند تا اطمینان حاصل شود کاری که با git commit یا دستورات مشابه در مخزن کامیت شده است، پایدارسازی می‌شود.
•added گزینه‌ای تجمیعی است که در حال حاضر معادل committed,index است. این حالت کارایی بیشتری را فدا می‌کند تا اطمینان حاصل شود نتایج دستوراتی مانند git add و عملیات مشابه پایدارسازی می‌شوند.
•all گزینه‌ای تجمیعی است که تمامی مؤلفه‌های منفرد فوق را همگام‌سازی (sync) می‌کند.

core.fsyncMethod

مقداری که راهبرد Git را برای پایدارسازی داده‌های مخزن با استفاده از fsync و دستورات اولیه مرتبط مشخص می‌کند.
•fsync از فراخوانی سیستمی fsync() یا معادل‌های آن در پلتفرم استفاده می‌کند.
•writeout-only درخواست‌های بازنویسی حافظه پنهان صفحه (pagecache writeback) را صادر می‌کند، اما بسته به سیستم فایل و سخت‌افزار ذخیره‌سازی، داده‌های اضافه‌شده به مخزن ممکن است در صورت وقوع خرابی سیستم (crash) پایدار نمانند. این حالت پیش‌فرض در macOS است.
•batch حالتی را فعال می‌کند که از تخلیه‌های فقط بازنویسی (writeout-only flushes) برای مرحله‌بندی چندین به‌روزرسانی در کش بازنویسی دیسک استفاده می‌کند و سپس یک fsync کامل روی یک فایل ساختگی انجام می‌دهد تا تخلیه کش دیسک را در پایان عملیات فعال سازد.

در حال حاضر حالت batch تنها برای فایل‌های loose-object اعمال می‌شود. سایر داده‌های مخزن به گونه‌ای پایدارسازی می‌شوند که گویی fsync مشخص شده است. انتظار می‌رود این حالت روی macOS برای مخازن ذخیره‌شده در سیستم‌های فایل HFS+ یا APFS و روی Windows برای مخازن ذخیره‌شده در سیستم‌های فایل NTFS یا ReFS به اندازه fsync امن باشد.

core.fsyncObjectFiles

این متغیر بولی fsync() را هنگام نوشتن فایل‌های شیء فعال می‌کند. این تنظیم منسوخ شده است. به جای آن از core.fsync استفاده کنید.

این تنظیم بر داده‌هایی اثر می‌گذارد که در قالب loose-object به مخزن گیت اضافه می‌شوند. در صورت تنظیم روی true، Git یک فراخوانی سیستمی fsync یا مشابه آن را برای تخلیه کش‌ها صادر می‌کند تا اشیاء مجزا (loose-objects) در مواجهه با خاموش شدن غیرعادی سیستم سازگار باقی بمانند.

core.preloadIndex

پیش‌بارگذاری موازی ایندکس را برای عملیاتی مانند git diff فعال می‌کند

این قابلیت می‌تواند به عملیاتی مانند git diff و git status به‌ویژه روی سیستم‌های فایلی مانند NFS که معناشناسی ضعیفی در کش کردن دارند و بنابراین تأخیر ورودی/خروجی (IO) نسبتاً بالایی دارند، سرعت ببخشد. در صورت فعال بودن، Git مقایسه ایندکس با داده‌های سیستم فایل را به صورت موازی انجام می‌دهد که امکان همپوشانی عملیات IO را فراهم می‌سازد. به طور پیش‌فرض true است.

core.unsetenvvars

فقط ویندوز: فهرستی جداشده با کاما از نام‌های متغیرهای محیطی که باید پیش از ایجاد هر فرآیند دیگری لغو (unset) شوند. به طور پیش‌فرض روی PERL5LIB تنظیم شده است تا این واقعیت را در نظر بگیرد که Git for Windows بر استفاده از مفسر پرل اختصاصی خود اصرار دارد.

core.createObject

می‌توانید این متغیر را روی link تنظیم کنید، که در این صورت از یک پیوند سخت (hardlink) و به دنبال آن حذف مبدا استفاده می‌شود تا اطمینان حاصل شود که ایجاد شیء، اشیاء موجود را بازنویسی نخواهد کرد.

در برخی ترکیب‌های سیستم فایل/سیستم‌عامل، این سازوکار غیرقابل اطمینان است. در آنجا این تنظیم پیکربندی را روی rename تنظیم کنید؛ با این حال، این کار بررسی اطمینان از بازنویسی نشدن فایل‌های شیء موجود را حذف خواهد کرد.

core.notesRef

هنگام نمایش پیام‌های کامیت، یادداشت‌هایی (notes) را که در ref داده‌شده ذخیره شده‌اند نیز نشان می‌دهد. این ref باید به طور کامل مشخص باشد (fully qualified). اگر ref داده‌شده وجود نداشته باشد، خطا به شمار نمی‌آید بلکه به این معناست که هیچ یادداشتی نباید چاپ شود.

این تنظیم به طور پیش‌فرض "refs/notes/commits" است، و می‌تواند توسط متغیر محیطی GIT_NOTES_REF بازنویسی شود. به git-notes(1) مراجعه کنید.

core.commitGraph

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

core.useReplaceRefs

اگر روی false تنظیم شود، طوری رفتار می‌کند که گویی گزینه --no-replace-objects در خط فرمان داده شده است. برای اطلاعات بیشتر به git(1) و git-replace(1) مراجعه کنید.

core.multiPackIndex

از فایل multi-pack-index برای ردگیری چندین packfile با استفاده از یک ایندکس واحد استفاده می‌کند. برای اطلاعات بیشتر به git-multi-pack-index(1) مراجعه کنید. به طور پیش‌فرض true است.

core.sparseCheckout

قابلیت "sparse checkout" (دریافت گزینشی/تنک) را فعال می‌کند. برای اطلاعات بیشتر به git-sparse-checkout(1) مراجعه کنید.

core.sparseCheckoutCone

"حالت مخروطی" (cone mode) قابلیت sparse checkout را فعال می‌کند. هنگامی که فایل sparse-checkout شامل مجموعه‌ای محدود از الگوها باشد، این حالت مزایای عملکردی قابل‌توجهی ارائه می‌دهد. می‌توان با تنظیم این متغیر روی false "حالت غیرمخروطی" را درخواست کرد تا امکان مشخص کردن الگوهای انعطاف‌پذیرتر فراهم شود. برای اطلاعات بیشتر به git-sparse-checkout(1) مراجعه کنید.

core.abbrev

طولی را که نام اشیاء به آن کوتاه می‌شوند تعیین می‌کند. اگر مشخص نشود یا روی "auto" تنظیم شود، مقداری مناسب بر اساس تعداد تقریبی اشیاء بسته‌بندی‌شده در مخزن شما محاسبه می‌شود، که امیدواریم کافی باشد تا نام‌های کوتاه اشیاء برای مدتی یکتا باقی بمانند. اگر روی "no" تنظیم شود، هیچ اختصاری صورت نمی‌گیرد و نام اشیاء با طول کامل نمایش داده می‌شوند. حداقل طول 4 است.

core.maxTreeDepth

حداکثر عمقی که Git مایل است هنگام پیمایش یک درخت وارد بازگشت (recurse) شود (برای نمونه، "a/b/cde/f" دارای عمق 4 است). این یک تدبیر ایمنی است تا به Git اجازه دهد به طور پاک متوقف شود، و عموماً نیازی به تغییر آن نیست. هنگامی که Git با MSVC کامپایل شده باشد، مقدار پیش‌فرض 512 است. در غیر این صورت، مقدار پیش‌فرض 2048 است.

credential.helper

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

توجه داشته باشید که می‌توان چندین دستیار کمکی تعریف کرد. برای جزئیات و مثال‌ها به gitcredentials(7) مراجعه کنید.

credential.interactive

به طور پیش‌فرض، Git و هر دستیار کمکی اعتبارنامه پیکربندی‌شده، در زمان نیاز به اطلاعات هویتی جدید، از کاربر درخواست ورودی می‌کنند. بسیاری از این دستیاران در صورتی که اطلاعات هویتی ذخیره‌شده هنوز معتبر باشند، بر اساس آن‌ها کار را با موفقیت انجام می‌دهند. برای جلوگیری از امکان تعامل با کاربر از سوی Git، مقدار credential.interactive=false را تنظیم کنید. برخی دستیاران کمکی اعتبارنامه نیز این گزینه را رعایت می‌کنند.

credential.useHttpPath

هنگام دریافت اطلاعات هویتی، مؤلفه "path" نشانی اینترنتی http یا https را مهم تلقی می‌کند. به طور پیش‌فرض false است. برای اطلاعات بیشتر به gitcredentials(7) مراجعه کنید.

credential.sanitizePrompt

به طور پیش‌فرض، نام‌های کاربری و میزبان‌هایی که به عنوان بخشی از اعلان گذرواژه نمایش داده می‌شوند مجاز به داشتن نویسه‌های کنترلی نیستند (آن‌ها به طور پیش‌فرض با کدگذاری URL نمایش می‌یابند). این تنظیم را روی false پیکربندی کنید تا این رفتار لغو شود.

credential.protectProtocol

به طور پیش‌فرض، نویسه‌های Carriage Return در پروتکلی که هنگام ارتباط Git با یک دستیار کمکی اعتبارنامه استفاده می‌شود مجاز نیستند. این تنظیم به کاربران امکان می‌دهد این مقدار پیش‌فرض را لغو کنند.

credential.username

اگر هیچ نام کاربری برای احراز هویت شبکه تنظیم نشده باشد، به طور پیش‌فرض از این نام کاربری استفاده می‌کند. به credential.<context>.* در ادامه، و gitcredentials(7) مراجعه کنید.

credential.<url>.*

هر یک از گزینه‌های credential.* بالا می‌تواند به صورت انتخابی برای برخی اطلاعات هویتی اعمال شود. برای نمونه، "credential.https://example.com.username" نام کاربری پیش‌فرض را تنها برای اتصالات https به example.com تنظیم می‌کند. برای جزئیات درباره نحوه تطبیق URLها، به gitcredentials(7) مراجعه کنید.

credentialCache.ignoreSIGHUP

به git-credential-cache—daemon اعلام می‌کند که سیگنال SIGHUP را به جای خروج نادیده بگیرد.

credentialStore.lockTimeoutMS

مدت زمان به میلی‌ثانیه برای تلاش مجدد git-credential-store هنگام تلاش برای قفل کردن فایل اطلاعات هویتی. مقدار 0 به معنای اصلاً تلاش مجدد نکردن است؛ -1 به معنای تلاش نامحدود است. پیش‌فرض 1000 است (یعنی تلاش مجدد برای 1 ثانیه).

diff.autoRefreshIndex

هنگام استفاده از git diff برای مقایسه با فایل‌های درخت کاری، تغییرات صرفاً مربوط به stat را به عنوان تغییریافته تلقی نمی‌کند. در عوض، به صورت خاموش git update-index --refresh را اجرا می‌کند تا اطلاعات کش‌شده stat را برای مسیرهایی که محتوای آن‌ها در درخت کاری با محتوای ایندکس مطابقت دارد به‌روزرسانی کند. این گزینه به طور پیش‌فرض true است. توجه داشته باشید که این موضوع تنها بر دستورات سطح بالای (Porcelain) git diff اثر می‌گذارد، و نه بر دستورات سطح پایین‌تر diff مانند git diff-files.

diff.dirstat

فهرستی جداشده با کاما از پارامترهای --dirstat که رفتار پیش‌فرض گزینه --dirstat را برای git-diff(1) و دستورات مرتبط مشخص می‌کند. مقادیر پیش‌فرض را می‌توان در خط فرمان بازنویسی کرد (با استفاده از --dirstat=<param>,...). پیش‌فرض‌های جایگزین (هنگامی که توسط diff.dirstat تغییر داده نشده باشند) عبارتند از changes,noncumulative,3. پارامترهای زیر در دسترس هستند:

changes

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

lines

اعداد dirstat را با انجام تحلیل معمول دیف مبتنی بر خط، و جمع کردن تعداد خطوط حذف‌شده/افزوده‌شده محاسبه می‌کند. (برای فایل‌های باینری، به جای آن تکه‌های 64 بایتی شمرده می‌شوند، زیرا فایل‌های باینری مفهوم طبیعی از خط ندارند). این رفتار --dirstat گران‌تر از رفتار changes است، اما خطوط جابه‌جاشده در یک فایل را به اندازه سایر تغییرات به شمار می‌آورد. خروجی حاصل با آنچه از سایر گزینه‌های --*stat به دست می‌آورید سازگار است.

files

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

cumulative

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

<limit>

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

مثال: عبارت زیر فایل‌های تغییریافته را می‌شمارد، در حالی که دایرکتوری‌های دارای کمتر از 10% از کل مقدار فایل‌های تغییریافته را نادیده می‌گیرد، و شمارش دایرکتوری‌های فرزند را در دایرکتوری‌های والد تجمیع می‌کند: files,10,cumulative.

diff.statNameWidth

عرض بخش نام فایل را در خروجی --stat محدود می‌کند. در صورت تنظیم، بر تمامی دستورات تولیدکننده خروجی --stat به جز format-patch اعمال می‌شود.

diff.statGraphWidth

عرض بخش نمودار را در خروجی --stat محدود می‌کند. در صورت تنظیم، بر تمامی دستورات تولیدکننده خروجی --stat به جز format-patch اعمال می‌شود.

diff.context

دیف‌ها را به جای پیش‌فرض 3، با <n> خط زمینه (context) تولید می‌کند. این مقدار توسط گزینه -U بازنویسی می‌شود.

diff.interHunkContext

زمینه میان تکه‌های دیف (hunks) را تا تعداد خطوط مشخص‌شده نمایش می‌دهد، و بدین ترتیب تکه‌هایی را که نزدیک یکدیگر هستند به هم پیوند می‌دهد. این مقدار به عنوان پیش‌فرض برای گزینه خط فرمان --inter-hunk-context عمل می‌کند.

diff.external

اگر این متغیر پیکربندی تنظیم شود، تولید دیف با استفاده از سازوکار داخلی دیف انجام نمی‌شود، بلکه با استفاده از دستور داده‌شده صورت می‌گیرد. می‌تواند با متغیر محیطی GIT_EXTERNAL_DIFF بازنویسی شود. این دستور با پارامترهایی فراخوانی می‌شود که در بخش "git Diffs" در git(1) توضیح داده شده است. نکته: اگر می‌خواهید از یک برنامه دیف خارجی تنها برای زیرمجموعه‌ای از فایل‌های خود استفاده کنید، ممکن است بهتر باشد به جای آن از gitattributes(5) استفاده کنید.

diff.trustExitCode

اگر این مقدار بولی روی true تنظیم شود، آنگاه انتظار می‌رود دستور diff.external در صورتی که فایل‌های ورودی را برابر بداند کد خروج 0 و اگر آن‌ها را متفاوت بداند کد خروج 1 را برگرداند، مانند diff(1). اگر روی false تنظیم شود، که پیش‌فرض است، آنگاه صرف‌نظر از برابری فایل‌ها، از دستور انتظار می‌رود کد خروج 0 را برگرداند. هر کد خروج دیگری باعث می‌شود Git یک خطای مهلک گزارش دهد.

diff.ignoreSubmodules

مقدار پیش‌فرض --ignore-submodules را تنظیم می‌کند. توجه داشته باشید که این موضوع تنها بر دستورات سطح بالای (Porcelain) git diff اثر می‌گذارد، و نه بر دستورات سطح پایین‌تر diff مانند git diff-files. دستورات git checkout و git switch نیز هنگام گزارش تغییرات کامیت‌نشده به این تنظیم احترام می‌گذارند. تنظیم آن روی all خلاصه زیرماژول را که معمولاً هنگام تنظیم status.submoduleSummary توسط git commit و git status نشان داده می‌شود غیرفعال می‌کند، مگر اینکه با استفاده از گزینه خط فرمان --ignore-submodules بازنویسی شود. دستورات git submodule تحت تأثیر این تنظیم قرار نمی‌گیرند. به طور پیش‌فرض این مقدار روی untracked تنظیم شده است تا هرگونه زیرماژول ردگیری‌نشده نادیده گرفته شود.

diff.mnemonicPrefix

در صورت تنظیم، git diff بسته به اینکه چه چیزی در حال مقایسه است، از یک جفت پیشوند متفاوت با پیشوند استاندارد a/ و b/ استفاده می‌کند. هنگامی که این پیکربندی برقرار باشد، خروجی دیف معکوس نیز ترتیب پیشوندها را جا‌به‌جا می‌کند:

git diff

ایندکس (i) و درخت کاری (w) را مقایسه می‌کند؛

git diff HEAD

یک کامیت (c) و درخت کاری (w) را مقایسه می‌کند؛

git diff --cached

یک کامیت (c) و ایندکس (i) را مقایسه می‌کند؛

git diff HEAD:<file1> <file2>

یک شیء (o) و یک موجودیت درخت کاری (w) را مقایسه می‌کند؛

git diff --no-index <a> <b>

دو مورد غیرگیت <a> و <b> را مقایسه می‌کند.

diff.noPrefix

در صورت تنظیم، git diff هیچ پیشوند مبدا یا مقصدی را نشان نمی‌دهد.

diff.srcPrefix

در صورت تنظیم، git diff از این پیشوند مبدا استفاده می‌کند. پیش‌فرض آن a/ است.

diff.dstPrefix

در صورت تنظیم، git diff از این پیشوند مقصد استفاده می‌کند. پیش‌فرض آن b/ است.

diff.relative

اگر روی true تنظیم شود، git diff تغییرات خارج از دایرکتوری را نشان نمی‌دهد و نام مسیرها را به صورت نسبی نسبت به دایرکتوری جاری نمایش می‌دهد.

diff.orderFile

فایلی که نحوه مرتب‌سازی فایل‌ها در یک دیف را مشخص می‌کند. برای جزئیات به گزینه -O در git-diff(1) مراجعه کنید. اگر diff.orderFile یک مسیر نسبی باشد، به عنوان مسیر نسبی نسبت به ریشه درخت کاری تلقی می‌شود. diff.renameLimit
تعداد فایل‌هایی که در بخش جامع تشخیص کپی/تغییر نام در نظر گرفته می‌شوند؛ معادل گزینه -l در git diff. اگر تنظیم نشود، مقدار پیش‌فرض در حال حاضر 1000 است. اگر تشخیص تغییر نام غیرفعال باشد، این تنظیم هیچ اثری ندارد.

diff.renames

آیا و چگونه Git تغییر نام‌ها را تشخیص می‌دهد. اگر بر روی false تنظیم شود، تشخیص تغییر نام غیرفعال می‌شود. اگر بر روی true تنظیم شود، تشخیص پایه تغییر نام فعال می‌گردد. اگر بر روی copies یا copy تنظیم شود، Git کپی‌ها را نیز تشخیص خواهد داد. پیش‌فرض true است. توجه داشته باشید که این مورد تنها بر دستورات سطح بالا (Porcelain) git diff مانند git-diff(1) و git-log(1) تأثیر می‌گذارد و بر دستورات سطح پایین‌تر مانند git-diff-files(1) اثری ندارد.

diff.suppressBlankEmpty

یک مقدار بولی برای بازداری از رفتار استاندارد چاپ فاصله (space) پیش از هر خط خروجی خالی. پیش‌فرض false است.

diff.submodule

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

diff.wordRegex

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

diff.<driver>.command

دستور درایور سفارشی diff. برای جزئیات به gitattributes(5) مراجعه کنید.

diff.<driver>.trustExitCode

اگر این مقدار بولی روی true تنظیم شود، آنگاه انتظار می‌رود دستور diff.<driver>.command در صورتی که فایل‌های ورودی را برابر بداند کد خروج 0 و در صورتی که آن‌ها را متفاوت بداند کد خروج 1 را برگرداند، مانند diff(1). اگر روی false تنظیم شود که مقدار پیش‌فرض است، آنگاه انتظار می‌رود دستور صرف‌نظر از برابری، کد خروج 0 برگرداند. هر کد خروج دیگری باعث می‌شود Git یک خطای مهلک گزارش کند.

diff.<driver>.xfuncname

عبارت باقاعده‌ای که درایور diff باید برای تشخیص سرآیند قطعه (hunk header) استفاده کند. همچنین می‌توان از یک الگوی توکار استفاده کرد. برای جزئیات به gitattributes(5) مراجعه کنید.

diff.<driver>.binary

این گزینه را روی true تنظیم کنید تا درایور diff فایل‌ها را به عنوان باینری در نظر بگیرد. برای جزئیات به gitattributes(5) مراجعه کنید.

diff.<driver>.textconv

دستوری که درایور diff باید برای تولید نسخه تبدیل‌شده به متنِ یک فایل فراخوانی کند. نتیجه تبدیل برای تولید یک diff خوانا برای انسان استفاده می‌شود. برای جزئیات به gitattributes(5) مراجعه کنید.

diff.<driver>.wordRegex

عبارت باقاعده‌ای که درایور diff باید برای تفکیک کلمات در یک خط استفاده کند. برای جزئیات به gitattributes(5) مراجعه کنید.

diff.<driver>.cachetextconv

این گزینه را روی true تنظیم کنید تا درایور diff خروجی‌های تبدیل متن را کِش کند. برای جزئیات به gitattributes(5) مراجعه کنید.

diff.indentHeuristic

این گزینه را روی false تنظیم کنید تا روش‌های اکتشافی پیش‌فرضی که مرزهای قطعه diff را تغییر می‌دهند تا وصله‌ها آسان‌تر خوانده شوند، غیرفعال گردند.

diff.algorithm

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

default, myers

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

minimal

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

patience

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

histogram

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

diff.wsErrorHighlight

خطاهای فضای خالی را در خطوط context، old یا new در diff برجسته کنید. مقادیر چندگانه با کاما جدا می‌شوند، none مقادیر قبلی را بازنشانی می‌کند، default فهرست را به new بازنشانی می‌نماید و all کوتاه‌شده‌ای برای old,new,context است. خطاهای فضای خالی با color.diff.whitespace رنگ‌آمیزی می‌شوند. گزینه خط فرمان --ws-error-highlight=<kind> این تنظیم را لغو می‌کند.

diff.colorMoved

اگر روی یک <mode> معتبر یا یک مقدار true تنظیم شود، خطوط جابجا شده در یک diff با رنگ متفاوتی نمایش داده می‌شوند. برای جزئیات حالت‌های معتبر، --color-moved در git-diff(1) را ببینید. اگر صرفاً روی true تنظیم شود، حالت رنگ پیش‌فرض استفاده خواهد شد. هنگامی که روی false تنظیم گردد، خطوط جابجا شده رنگ‌آمیزی نمی‌شوند.

diff.colorMovedWS

هنگامی که خطوط جابجا شده مثلاً با استفاده از تنظیم diff.colorMoved رنگ‌آمیزی می‌شوند، این گزینه نحوه برخورد با فاصله‌ها را کنترل می‌کند. برای جزئیات حالت‌های معتبر، --color-moved-ws در git-diff(1) را ببینید.

diff.tool

کنترل می‌کند که کدام ابزار diff توسط git-difftool(1) استفاده شود. این متغیر مقدار پیکربندی‌شده در merge.tool را لغو می‌کند. فهرست زیر مقادیر توکار معتبر را نشان می‌دهد. هر مقدار دیگری به عنوان یک ابزار diff سفارشی در نظر گرفته می‌شود و مستلزم آن است که متغیر متناظر difftool.<tool>.cmd تعریف شده باشد.

diff.guitool

کنترل می‌کند که هنگام مشخص شدن فلگ -g/--gui، کدام ابزار diff توسط git-difftool(1) استفاده شود. این متغیر مقدار پیکربندی‌شده در merge.guitool را لغو می‌کند. فهرست زیر مقادیر توکار معتبر را نشان می‌دهد. هر مقدار دیگری به عنوان یک ابزار diff سفارشی در نظر گرفته می‌شود و مستلزم آن است که متغیر متناظر difftool.<guitool>.cmd تعریف شده باشد.

araxis

استفاده از Araxis Merge (نیازمند نشست گرافیکی)

bc

استفاده از Beyond Compare (نیازمند نشست گرافیکی)

bc3

استفاده از Beyond Compare (نیازمند نشست گرافیکی)

bc4

استفاده از Beyond Compare (نیازمند نشست گرافیکی)

codecompare

استفاده از Code Compare (نیازمند نشست گرافیکی)

deltawalker

استفاده از DeltaWalker (نیازمند نشست گرافیکی)

diffmerge

استفاده از DiffMerge (نیازمند نشست گرافیکی)

diffuse

استفاده از Diffuse (نیازمند نشست گرافیکی)

ecmerge

استفاده از ECMerge (نیازمند نشست گرافیکی)

emerge

استفاده از Emacs' Emerge

examdiff

استفاده از ExamDiff Pro (نیازمند نشست گرافیکی)

guiffy

استفاده از Guiffy’s Diff Tool (نیازمند نشست گرافیکی)

gvimdiff

استفاده از gVim (نیازمند نشست گرافیکی)

kdiff3

استفاده از KDiff3 (نیازمند نشست گرافیکی)

kompare

استفاده از Kompare (نیازمند نشست گرافیکی)

meld

استفاده از Meld (نیازمند نشست گرافیکی)

nvimdiff

استفاده از Neovim

opendiff

استفاده از FileMerge (نیازمند نشست گرافیکی)

p4merge

استفاده از HelixCore P4Merge (نیازمند نشست گرافیکی)

smerge

استفاده از Sublime Merge (نیازمند نشست گرافیکی)

tkdiff

استفاده از TkDiff (نیازمند نشست گرافیکی)

vimdiff

استفاده از Vim

vscode

استفاده از Visual Studio Code (نیازمند نشست گرافیکی)

winmerge

استفاده از WinMerge (نیازمند نشست گرافیکی)

xxdiff

استفاده از xxdiff (نیازمند نشست گرافیکی)

difftool.<tool>.cmd

دستور لازم برای فراخوانی ابزار diff مشخص‌شده را معین می‌کند. دستور مشخص‌شده در شل با در دسترس بودن متغیرهای زیر ارزیابی می‌شود: LOCAL روی نام فایل موقت حاوی محتویات پیش‌تصویر diff (pre-image) تنظیم می‌شود و REMOTE روی نام فایل موقت حاوی محتویات پس‌تصویر diff (post-image) تنظیم می‌گردد.

برای جزئیات بیشتر به گزینه --tool=<tool> در git-difftool(1) مراجعه کنید.

difftool.<tool>.path

مسیر ابزار داده‌شده را لغو می‌کند. این در مواردی مفید است که ابزار شما در PATH قرار ندارد.

difftool.trustExitCode

اگر ابزار diff فراخوانی‌شده وضعیت خروج غیرصفر برگرداند، از difftool خارج شود.

برای جزئیات بیشتر به گزینه --trust-exit-code در git-difftool(1) مراجعه کنید.

difftool.prompt

قبل از هر بار فراخوانی ابزار diff اعلان تأیید نمایش داده شود.

difftool.guiDefault

روی true تنظیم کنید تا به صورت پیش‌فرض از diff.guitool استفاده شود (معادل با مشخص کردن آرگومان --gui)، یا auto برای انتخاب diff.guitool یا diff.tool بسته به وجود مقدار متغیر محیطی DISPLAY. پیش‌فرض false است، که در آن آرگومان --gui باید صراحتاً ارائه شود تا diff.guitool استفاده گردد.

extensions.*

مگر در مواردی که خلاف آن ذکر شده باشد، اگر core.repositoryFormatVersion برابر 1 نباشد، مشخص کردن یک افزونه خطا است. به gitrepository-layout(5) مراجعه کنید.

compatObjectFormat

یک الگوریتم هش سازگاری را برای استفاده مشخص می‌کند. مقادیر قابل قبول sha1 و sha256 هستند. مقدار مشخص‌شده باید با مقدار extensions.objectFormat متفاوت باشد. این امر امکان تعامل‌پذیری در سطح کلاینت را بین مخازن گیت که objectFormat آن‌ها با این compatObjectFormat مطابقت دارد فراهم می‌آورد. به‌ویژه هنگامی که به طور کامل پیاده‌سازی شود، پوش‌ها و پول‌ها از مخزنی که objectFormat آن با compatObjectFormat مطابقت دارد انجام می‌شود، و همچنین امکان استفاده از oidهای کدگذاری‌شده در compatObjectFormat علاوه بر oidهای کدگذاری‌شده با objectFormat برای مشخص کردن اشیاء به صورت محلی وجود خواهد داشت.

توجه داشته باشید عملکردی که توسط این افزونه فعال می‌شود ناقص بوده و در معرض تغییر است. این قابلیت در حال حاضر تنها برای امکان توسعه و آزمایش ویژگی زیربنایی وجود دارد و برای فعال‌سازی توسط کاربران نهایی طراحی نشده است.

noop

این افزونه رفتار گیت را به هیچ وجه تغییر نمی‌دهد. این افزونه تنها برای آزمایش سازگاری با فرمت ۱ مفید است.

به دلایل تاریخی، این افزونه صرف‌نظر از تنظیم core.repositoryFormatVersion رعایت می‌شود.

noop-v1

این افزونه رفتار گیت را به هیچ وجه تغییر نمی‌دهد. این افزونه تنها برای آزمایش سازگاری با فرمت ۱ مفید است.

objectFormat

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

توجه داشته باشید که این تنظیم تنها باید توسط git-init(1) یا git-clone(1) تنظیم شود. تلاش برای تغییر آن پس از مقداردهی اولیه کار نخواهد کرد و مشکلاتی به وجود می‌آورد که عیب‌یابی آن‌ها دشوار است.

partialClone

هنگام فعال بودن، نشان می‌دهد که مخزن با یک کلون جزئی ایجاد شده است (یا بعداً واکشی جزئی انجام داده است) و اینکه ریموت ممکن است از ارسال اشیاء ناخواسته خاصی صرف‌نظر کرده باشد. چنین ریموتی «promisor remote» (ریموت متعهد) نامیده می‌شود و قول می‌دهد که تمام اشیاء حذف‌شده این‌چنینی را می‌توان در آینده از آن واکشی کرد.

مقدار این کلید، نام ریموت متعهد است.

به دلایل تاریخی، این افزونه صرف‌نظر از تنظیم core.repositoryFormatVersion رعایت می‌شود.

preciousObjects

در صورت فعال بودن، نشان می‌دهد که اشیاء موجود در مخزن نباید حذف شوند (مثلاً توسط git-prune یا git repack -d).

به دلایل تاریخی، این افزونه صرف‌نظر از تنظیم core.repositoryFormatVersion رعایت می‌شود.

refStorage

فرمت ذخیره‌سازی مراجع و محموله (payload) متناظر آن را مشخص می‌کند. مقدار می‌تواند یک نام فرمت یا یک URI باشد:
•تنها یک نام فرمت (مثلاً reftable یا files).
•یک فرمت URI <format>://<payload> که صراحتاً هم فرمت و هم محموله را مشخص می‌کند (مثلاً reftable:///foo/bar).

نام‌های فرمت پشتیبانی‌شده عبارتند از:

files

برای فایل‌های مستقل همراه با packed-refs. این حالت پیش‌فرض است.

reftable

برای فرمت reftable.

محموله مستقیماً به بک‌اند مراجع ارسال می‌شود. برای بک‌اندهای files و reftable، این باید یک مسیر سیستم‌فایل باشد که مراجع در آن ذخیره می‌شوند. در صورتی که محموله‌ای ارائه نشود، به طور پیش‌فرض commondir در نظر گرفته می‌شود. مسیرهای نسبی نسبت به $GIT_DIR حل می‌شوند. بک‌اندهای آینده ممکن است از طرح‌های محموله دیگری پشتیبانی کنند، مثلاً postgres://127.0.0.1:5432?database=myrepo.

توجه داشته باشید که این تنظیم تنها باید توسط git-init(1) یا git-clone(1) تنظیم شود. تلاش برای تغییر آن پس از مقداردهی اولیه کار نخواهد کرد و مشکلاتی به وجود می‌آورد که عیب‌یابی آن‌ها دشوار است.

relativeWorktrees

در صورت فعال بودن، نشان می‌دهد حداقل یک درخت کاری با مسیرهای نسبی پیوند داده شده است. اگر یک درخت کاری با گزینه --relative-paths یا با تنظیم پیکربندی worktree.useRelativePaths روی true ایجاد یا تعمیر شده باشد، به طور خودکار تنظیم می‌گردد.

submodulePathConfig

این افزونه برای اقلیتی از کاربران است که:
•به دلایل مختلف، مانند تداخل‌های سیستم‌فایل غیرحساس به حروف کوچک و بزرگ هنگام ایجاد ماژول‌هایی با نام‌های foo و Foo، با خطاهایی مانند refusing to create ... in another submodule's git dir مواجه می‌شوند.
•به ساختاربندی‌های انعطاف‌پذیرتری برای زیرماژول‌ها نیاز دارند، برای مثال به دلیل نام‌های تو در تو مانند foo، foo/bar و foo/baz که توسط سازوکار پیش‌فرض gitdir که از مکان‌های .git/modules/<plain-name> استفاده می‌کند پشتیبانی نمی‌شوند، و باعث تداخل‌های بیشتری می‌گردند.

هنگامی که extensions.submodulePathConfig فعال باشد، پیکربندی submodule.<name>.gitdir به تنها مرجع واحد حقیقت برای تمام مسیرهای gitdir زیرماژول‌ها تبدیل می‌شود و برای تمام زیرماژول‌های جدید هم در طول عملیات clone و هم init به صورت خودکار تنظیم می‌گردد.

اگر یک ماژول تنظیم متناظر submodule.<name>.gitdir را نداشته باشد، Git با خطا مواجه خواهد شد.

زیرماژول‌های موجود (پیش از فعال‌سازی افزونه) باید با افزودن ورودی‌های پیکربندی ناموجود مهاجرت داده شوند. این کار می‌تواند به صورت دستی انجام شود، مثلاً برای هر زیرماژول: git config submodule.<name>.gitdir .git/modules/<name>، یا از طریق دستور git submodule--helper migrate-gitdir-configs که روی تمام زیرماژول‌ها پیمایش کرده و تلاش می‌کند آن‌ها را مهاجرت دهد.

این افزونه می‌تواند با تنظیم init.defaultSubmodulePathConfig روی true، به طور خودکار برای مخازن جدید فعال شود، برای مثال با اجرای git config --global init.defaultSubmodulePathConfig true.

worktreeConfig

در صورت فعال بودن، درخت‌های کاری تنظیمات پیکربندی را علاوه بر فایل $GIT_COMMON_DIR/config از فایل $GIT_DIR/config.worktree نیز بارگذاری خواهند کرد. توجه داشته باشید که $GIT_COMMON_DIR و $GIT_DIR برای درخت کاری اصلی یکسان هستند، در حالی که سایر درخت‌های کاری دارای $GIT_DIR برابر با $GIT_COMMON_DIR/worktrees/<id>/ می‌باشند. تنظیمات موجود در فایل config.worktree تنظیمات هر فایل پیکربندی دیگری را لغو خواهند کرد.

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

•core.worktree باید از $GIT_COMMON_DIR/config به $GIT_COMMON_DIR/config.worktree منتقل شود.
•اگر core.bare برابر true باشد، آنگاه باید از $GIT_COMMON_DIR/config به $GIT_COMMON_DIR/config.worktree منتقل شود.

همچنین ممکن است بسته به تمایل شما برای تنظیمات سفارشی‌سازی‌پذیر sparse-checkout برای هر درخت کاری، تنظیم مکان‌های core.sparseCheckout و core.sparseCheckoutCone مفید باشد. به طور پیش‌فرض، دستور توکار git sparse-checkout این افزونه را فعال می‌کند، این مقادیر پیکربندی را بر مبنای هر درخت کاری اختصاص می‌دهد، و از فایل $GIT_DIR/info/sparse-checkout برای تعیین میزان پراکندگی برای هر درخت کاری به طور مستقل استفاده می‌کند. برای جزئیات بیشتر به git-sparse-checkout(1) مراجعه کنید.

به دلایل تاریخی، این افزونه صرف‌نظر از تنظیم core.repositoryFormatVersion رعایت می‌شود.

fastimport.unpackLimit

اگر تعداد اشیاء واردشده توسط git-fast-import(1) کمتر از این حد باشد، اشیاء به صورت فایل‌های شیء مستقل از بسته‌بندی خارج می‌شوند. اما اگر تعداد اشیاء واردشده برابر یا بیشتر از این حد باشد، بسته به صورت یک فایل بسته (pack) ذخیره خواهد شد. ذخیره بسته حاصل از fast-import می‌تواند باعث شود عملیات ورود سریع‌تر انجام شود، به‌ویژه روی سیستم‌های فایلی کند. در صورت عدم تنظیم، مقدار transfer.unpackLimit به جای آن استفاده می‌شود.

feature.*

تنظیمات پیکربندی که با feature. شروع می‌شوند، مقادیر پیش‌فرض گروهی از تنظیمات پیکربندی دیگر را تغییر می‌دهند. این گروه‌ها توسط جامعه توسعه‌دهندگان Git به عنوان پیش‌فرض‌های توصیه‌شده ایجاد شده‌اند و در معرض تغییر هستند. به‌ویژه، ممکن است گزینه‌های پیکربندی جدیدی با پیش‌فرض‌های متفاوت اضافه شوند.

feature.experimental

گزینه‌های پیکربندی را که در Git جدید هستند و برای پیش‌فرض‌های آینده در نظر گرفته شده‌اند فعال کنید. تنظیمات پیکربندی گنجانده‌شده در اینجا ممکن است با هر انتشار، از جمله به‌روزرسانی‌های نگارش‌های فرعی، اضافه یا حذف شوند. این تنظیمات ممکن است به دلیل جدید بودن، اثرات متقابل ناخواسته‌ای داشته باشند. لطفاً اگر علاقه‌مند به ارائه بازخورد در مورد ویژگی‌های آزمایشی هستید، این تنظیم را فعال کنید. مقادیر پیش‌فرض جدید عبارتند از:
•fetch.negotiationAlgorithm=skipping ممکن است با پرش از روی کامیت‌های بیشتر در هر مرحله، زمان مذاکره واکشی را بهبود بخشد و تعداد رفت‌وبرگشت‌ها را کاهش دهد.
•pack.useBitmapBoundaryTraversal=true ممکن است با پیمایش اشیاء کمتر، زمان پیمایش نگاشت بیتی را بهبود بخشد.
•pack.allowPackReuse=multi ممکن است زمان لازم برای ایجاد یک بسته را با استفاده مجدد از اشیاءِ چند بسته به جای تنها یک بسته بهبود بخشد.
•pack.usePathWalk ممکن است ایجاد فایل بسته را سرعت بخشد و اندازه فایل‌های بسته را در حضور تداخل‌های خاص نام فایل با هش پیش‌فرض نام در Git به طور چشمگیری کوچک‌تر کند.
•init.defaultRefFormat=reftable باعث می‌شود مخازن تازه مقداردهی‌شده از فرمت reftable برای ذخیره‌سازی مراجع استفاده کنند. این فرمت جدید مشکلات مربوط به سیستم‌های فایلی غیرحساس به حروف کوچک و بزرگ را برطرف می‌کند، فشرده‌سازی بهتری دارد و در بسیاری از موارد کاربرد عملکرد بسیار بهتری ارائه می‌دهد. برای اطلاعات بیشتر در مورد این فرمت ذخیره‌سازی جدید به Documentation/technical/reftable.adoc مراجعه کنید.

feature.manyFiles

گزینه‌های پیکربندی را فعال می‌کند که برای مخازنی با تعداد فایل‌های بسیار در دایرکتوری کاری بهینه‌سازی شده‌اند. با وجود فایل‌های بسیار، دستوراتی مانند git status و git checkout ممکن است کند باشند و این پیش‌فرض‌های جدید عملکرد را بهبود می‌بخشند:
•index.skipHash=true با محاسبه نکردن جمع کنترلی پایانی، نوشتن در ایندکس را سرعت می‌بخشد. توجه داشته باشید که این امر باعث می‌شود نگارش‌های Git قدیمی‌تر از 2.13.0 از تجزیه ایندکس خودداری کنند و نگارش‌های Git قدیمی‌تر از 2.40.0 در حین اجرای git fsck یک ایندکس خراب را گزارش دهند.
•index.version=4 فشرده‌سازی پیشوند مسیر را در ایندکس فعال می‌کند.
•core.untrackedCache=true کِش فایل‌های ردگیری‌نشده را فعال می‌کند. این تنظیم فرض می‌کند که mtime روی سیستم شما کار می‌کند.

fetch.recurseSubmodules

این گزینه کنترل می‌کند که آیا git fetch (و واکشی زیربنایی در git pull) به صورت بازگشتی در زیرماژول‌های پرشده واکشی انجام دهد یا خیر. این گزینه می‌تواند روی یک مقدار بولی یا روی on-demand تنظیم شود. تنظیم آن روی یک مقدار بولی رفتار fetch و pull را تغییر می‌دهد تا در صورت تنظیم روی true بدون قید و شرط به صورت بازگشتی وارد زیرماژول‌ها شوند، یا در صورت تنظیم روی false اصلاً بازگشتی عمل نکنند. هنگامی که روی on-demand تنظیم شود، fetch و pull تنها زمانی به صورت بازگشتی وارد یک زیرماژول پرشده می‌شوند که ابرپروژه آن کامیتی را دریافت کند که مرجع زیرماژول را به‌روزرسانی نماید. پیش‌فرض on-demand است، یا مقدار submodule.recurse در صورت تنظیم بودن.

fetch.fsckObjects

اگر روی true تنظیم شود، git-fetch-pack تمام اشیاء واکشی‌شده را بررسی خواهد کرد. برای آنچه بررسی می‌شود به transfer.fsckObjects مراجعه کنید. پیش‌فرض false است. در صورت عدم تنظیم، مقدار transfer.fsckObjects به جای آن استفاده می‌شود.

fetch.fsck.<msg-id>

مانند fsck.<msg-id> عمل می‌کند، اما به جای git-fsck(1) توسط git-fetch-pack(1) استفاده می‌شود. برای جزئیات به مستندات fsck.<msg-id> مراجعه کنید.

fetch.fsck.skipList

مانند fsck.skipList عمل می‌کند، اما به جای git-fsck(1) توسط git-fetch-pack(1) استفاده می‌شود. برای جزئیات به مستندات fsck.skipList مراجعه کنید.

fetch.unpackLimit

اگر تعداد اشیاء واکشی‌شده از طریق انتقال بومی Git کمتر از این حد باشد، اشیاء به صورت فایل‌های شیء مستقل از بسته‌بندی خارج می‌شوند. اما اگر تعداد اشیاء دریافت‌شده برابر یا بیشتر از این حد باشد، بسته دریافت‌شده پس از افزودن هرگونه پایه‌های دلتای ناموجود، به عنوان یک بسته ذخیره خواهد شد. ذخیره بسته حاصل از ارسال می‌تواند باعث شود عملیات ارسال سریع‌تر انجام شود، به‌ویژه روی سیستم‌های فایلی کند. در صورت عدم تنظیم، مقدار transfer.unpackLimit به جای آن استفاده می‌شود.

fetch.prune

اگر true باشد، fetch به طور خودکار به گونه‌ای عمل می‌کند که گویی گزینه --prune در خط فرمان داده شده است. همچنین به remote.<name>.prune و بخش PRUNING در git-fetch(1) مراجعه کنید.

fetch.pruneTags

اگر true باشد، fetch در هنگام هرس به طور خودکار به گونه‌ای عمل می‌کند که گویی مشخصه مرجع refs/tags/*:refs/tags/* ارائه شده است، البته اگر قبلاً تنظیم نشده باشد. این امر امکان تنظیم هر دوی این گزینه و fetch.prune را برای حفظ نگاشت ۱ به ۱ با مراجع بالادست فراهم می‌کند. همچنین به remote.<name>.pruneTags و بخش PRUNING در git-fetch(1) مراجعه کنید.

fetch.all

اگر true باشد، fetch تلاش می‌کند تمام ریموت‌های موجود را به‌روزرسانی کند. این رفتار را می‌توان با فرستادن --no-all یا با مشخص کردن صریح یک یا چند ریموت برای واکشی لغو کرد. پیش‌فرض false است.

fetch.output

نحوه چاپ وضعیت به‌روزرسانی مراجع را کنترل می‌کند. مقادیر معتبر عبارتند از full و compact. مقدار پیش‌فرض full است. برای جزئیات به بخش OUTPUT در git-fetch(1) مراجعه کنید.

fetch.negotiationAlgorithm

نحوه ارسال اطلاعات مربوط به کامیت‌ها در مخزن محلی را هنگام مذاکره بر سر محتویات فایل بسته ارسالی توسط سرور کنترل می‌کند. روی consecutive تنظیم کنید تا از الگوریتمی استفاده شود که کامیت‌های متوالی را پیمایش کرده و تک‌تک آن‌ها را بررسی می‌کند. روی skipping تنظیم کنید تا از الگوریتمی استفاده شود که کامیت‌ها را با هدف همگرایی سریع‌تر نادیده می‌گیرد، اما ممکن است منجر به فایل بسته‌ای بزرگ‌تر از حد نیاز شود؛ یا روی noop تنظیم کنید تا اصلاً هیچ اطلاعاتی ارسال نشود، که تقریباً به طور قطع منجر به فایل بسته‌ای بزرگ‌تر از حد نیاز خواهد شد، اما مرحله مذاکره را دور می‌زند. روی default تنظیم کنید تا تنظیمات اعمال‌شده قبلی لغو شده و از رفتار پیش‌فرض استفاده گردد. پیش‌فرض معمولاً consecutive است، اما اگر feature.experimental برابر true باشد، آنگاه پیش‌فرض skipping خواهد بود. مقادیر ناشناخته باعث خطای git fetch می‌شوند.

همچنین گزینه‌های --negotiate-only و --negotiation-restrict در git-fetch(1) را ببینید.

fetch.showForcedUpdates

روی false تنظیم کنید تا --no-show-forced-updates در دستورات git-fetch(1) و git-pull(1) فعال شود. پیش‌فرض true است.

fetch.parallel

حداکثر تعداد عملیات واکشی را که می‌توانند به طور هم‌زمان و موازی اجرا شوند مشخص می‌کند (زیرماژول‌ها، یا ریموت‌ها هنگامی که گزینه --multiple در git-fetch(1) اعمال شده باشد).

مقدار 0 یک پیش‌فرض معقول تعیین می‌کند. اگر تنظیم نشود، پیش‌فرض 1 است.

برای زیرماژول‌ها، این تنظیم را می‌توان با استفاده از تنظیم پیکربندی submodule.fetchJobs لغو کرد.

fetch.writeCommitGraph

روی true تنظیم کنید تا پس از هر دستور git fetch که یک فایل بسته را از ریموت دانلود می‌کند، یک commit-graph نوشته شود. با استفاده از گزینه --split، بیشتر اجراها یک فایل commit-graph بسیار کوچک روی فایل(های) commit-graph موجود ایجاد می‌کنند. گاهی اوقات این فایل‌ها ادغام می‌شوند و نوشتن ممکن است طولانی‌تر شود. داشتن یک فایل commit-graph به‌روز به عملکرد بسیاری از دستورات Git کمک می‌کند، از جمله git merge-base، git push -f، و git log --graph. پیش‌فرض false است.

fetch.bundleURI

این مقدار یک URI را برای دانلود داده‌های شیء Git از یک bundle URI قبل از انجام واکشی افزایشی از سرور اصلی Git ذخیره می‌کند. این شبیه به نحوه رفتار گزینه --bundle-uri در git-clone(1) است. دستور git clone --bundle-uri در صورتی که bundle URI ارائه‌شده شامل فهرست بسته‌ای باشد که برای واکشی‌های افزایشی سازمان‌یافته است، مقدار fetch.bundleURI را تنظیم می‌کند.

اگر این مقدار را تغییر دهید و مخزن شما دارای مقدار fetch.bundleCreationToken باشد، پیش از واکشی از bundle URI جدید، آن مقدار fetch.bundleCreationToken را حذف کنید.

fetch.bundleCreationToken

هنگام استفاده از fetch.bundleURI برای واکشی افزایشی از یک فهرست بسته که از روش اکتشافی «creationToken» استفاده می‌کند، این مقدار پیکربندی حداکثر مقدار creationToken بسته‌های دانلودشده را ذخیره می‌کند. این مقدار برای جلوگیری از دانلود بسته‌ها در آینده استفاده می‌شود اگر creationToken اعلام‌شده اکیداً بزرگ‌تر از این مقدار نباشد.

مقادیر توکن ایجاد توسط ارائه‌دهنده‌ای که bundle URI خاص را ارائه می‌دهد انتخاب می‌شوند. اگر URI را در fetch.bundleURI تغییر دادید، حتماً پیش از واکشی مقدار fetch.bundleCreationToken را حذف کنید.

filter.<driver>.clean

دستوری که برای تبدیل محتوای یک فایل درخت کاری به یک blob در هنگام ثبت (checkin) استفاده می‌شود. برای جزئیات به gitattributes(5) مراجعه کنید.

filter.<driver>.smudge

دستوری که برای تبدیل محتوای یک شیء blob به یک فایل درخت کاری در هنگام وارسی (checkout) استفاده می‌شود. برای جزئیات به gitattributes(5) مراجعه کنید.

format.attach

پیوست‌های multipart/mixed را به عنوان پیش‌فرض برای format-patch فعال می‌کند. مقدار همچنین می‌تواند یک رشته درون گیومه باشد که پیوست‌ها را به عنوان پیش‌فرض فعال کرده و آن مقدار را به عنوان مرز (boundary) تنظیم کند. گزینه --attach را در git-format-patch(1) ببینید. برای باطل کردن یک مقدار قبلی، آن را روی رشته خالی تنظیم کنید.

format.from

مقدار پیش‌فرض را برای گزینه --from در format-patch فراهم می‌کند. یک مقدار بولی، یا یک نام و نشانی ایمیل را می‌پذیرد. اگر false باشد، format-patch به صورت پیش‌فرض روی --no-from قرار می‌گیرد و از نویسندگان کامیت مستقیماً در فیلد «From:» ایمیل‌های وصله استفاده می‌کند. اگر true باشد، format-patch به صورت پیش‌فرض روی --from قرار می‌گیرد و از هویت کامیت‌کننده شما در فیلد «From:» ایمیل‌های وصله استفاده می‌نماید و در صورت تفاوت، یک فیلد «From:» در بدنه ایمیل وصله درج می‌کند. اگر روی یک مقدار غیربولی تنظیم شود، format-patch از آن مقدار به جای هویت کامیت‌کننده شما استفاده می‌کند. پیش‌فرض false است.

format.forceInBodyFrom

مقدار پیش‌فرض را برای گزینه --[no-]force-in-body-from در format-patch فراهم می‌کند. پیش‌فرض false است.

format.numbered

یک مقدار بولی که می‌تواند شماره‌های ترتیبی را در موضوعات وصله فعال یا غیرفعال کند. پیش‌فرض آن «auto» است که فقط در صورت وجود بیش از یک وصله آن را فعال می‌کند. با تنظیم آن روی «true» یا «false» می‌توان آن را برای همه پیام‌ها فعال یا غیرفعال کرد. گزینه --numbered در git-format-patch(1) را ببینید.

format.headers

سرآیندهای ایمیل اضافی برای گنجاندن در وصله‌ای که قرار است با ایمیل ارسال شود. به git-format-patch(1) مراجعه کنید.

format.to, format.cc

گیرندگان اضافی برای گنجاندن در وصله‌ای که قرار است با ایمیل ارسال شود. گزینه‌های --to و --cc را در git-format-patch(1) ببینید.

format.subjectPrefix

پیش‌فرض برای format-patch خروجی دادن فایل‌ها با پیشوند موضوع [PATCH] است. از این متغیر برای تغییر آن پیشوند استفاده کنید.

format.coverFromDescription

حالت پیش‌فرض برای format-patch جهت تعیین اینکه کدام بخش‌های نامه پوششی با استفاده از توضیحات شاخه پر می‌شوند. گزینه --cover-from-description در git-format-patch(1) را ببینید.

format.signature

پیش‌فرض برای format-patch خروجی دادن امضایی حاوی شماره نسخه Git است. از این متغیر برای تغییر آن پیش‌فرض استفاده کنید. این متغیر را روی رشته خالی ("") تنظیم کنید تا از تولید امضا جلوگیری شود.

format.signatureFile

دقیقاً مانند format.signature کار می‌کند مگر آنکه محتویات فایل مشخص‌شده توسط این متغیر به عنوان امضا استفاده خواهد شد.

format.suffix

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

format.encodeEmailHeaders

سرآیندهای ایمیل دارای نویسه‌های غیر ASCII را با «Q-encoding» (توصیف‌شده در RFC 2047) برای ارسال از طریق ایمیل کدگذاری می‌کند. پیش‌فرض true است.

format.pretty

قالب زیبای پیش‌فرض برای دستورات log/show/whatchanged. به git-log(1)، git-show(1)، git-whatchanged(1) مراجعه کنید.

format.thread

سبک پیش‌فرض رشته‌بندی (threading) برای git format-patch. می‌تواند یک مقدار بولی، یا shallow یا deep باشد. رشته‌بندی shallow کاری می‌کند که هر ایمیل پاسخی به سرِ مجموعه (head of the series) باشد، که در آن سرِ مجموعه به ترتیب از نامه روی جلد (cover letter)، --in-reply-to و اولین ایمیل وصله انتخاب می‌شود. رشته‌بندی deep هر ایمیل را به پاسخی برای ایمیل قبلی تبدیل می‌کند. مقدار بولی درست (true) معادل shallow است و مقدار نادرست (false) رشته‌بندی را غیرفعال می‌کند.

format.signOff

یک مقدار بولی که به شما امکان می‌دهد گزینه -s/--signoff در format-patch را به‌طور پیش‌فرض فعال کنید. توجه: افزودن دنباله (trailer) Signed-off-by به یک وصله باید اقدامی آگاهانه باشد و بدین معناست که شما گواهی می‌دهید حق ارسال این اثر را تحت همان مجوز متن‌باز دارید. لطفاً برای توضیحات بیشتر به سند SubmittingPatches مراجعه کنید.

format.coverLetter

یک مقدار بولی که کنترل می‌کند آیا هنگام فراخوانی format-patch نامه روی جلد (cover-letter) ایجاد شود یا خیر؛ علاوه بر این می‌تواند روی "auto" تنظیم شود تا تنها زمانی که بیش از یک وصله وجود دارد نامه روی جلد ایجاد گردد. پیش‌فرض false است.

format.commitListFormat

هنگامی که گزینه --commit-list-format داده نشده باشد، format-patch از مقدار این متغیر برای تصمیم‌گیری در مورد نحوه قالب‌بندی مدخل هر کامیت استفاده می‌کند. پیش‌فرض shortlog است.

format.outputDirectory

یک پوشه سفارشی را برای ذخیره فایل‌های خروجی به جای پوشه کاری فعلی تنظیم می‌کند. تمام بخش‌های مسیر پوشه در صورت نیاز ایجاد خواهند شد.

format.filenameMaxLength

حداکثر طول نام فایل‌های خروجی تولیدشده توسط دستور format-patch؛ پیش‌فرض 64 است. می‌تواند با گزینه خط فرمان --filename-max-length=<n> بازنویسی (override) شود.

format.useAutoBase

یک مقدار بولی که به شما امکان می‌دهد گزینه --base=auto در format-patch را به‌طور پیش‌فرض فعال کنید. همچنین می‌تواند روی "whenAble" تنظیم شود تا در صورت در دسترس بودن یک پایه (base) مناسب، --base=auto فعال گردد، اما در غیر این صورت بدون متوقف شدن و خطای فرآیند، از افزودن اطلاعات پایه صرف‌نظر شود.

format.notes

مقدار پیش‌فرض گزینه --notes را برای format-patch فراهم می‌کند. یک مقدار بولی یا یک مرجع (ref) را می‌پذیرد که مشخص می‌کند یادداشت‌ها از کجا دریافت شوند. اگر false باشد، format-patch به‌طور پیش‌فرض از --no-notes استفاده می‌کند. اگر true باشد، format-patch به‌طور پیش‌فرض از --notes استفاده می‌کند. اگر روی یک مقدار غیربولی تنظیم شود، format-patch به‌طور پیش‌فرض از --notes=<ref> استفاده می‌کند، که در آن ref همان مقدار غیربولی است. پیش‌فرض false است.

اگر کسی بخواهد از مرجع refs/notes/true استفاده کند، لطفاً در عوض از همان عبارت دقیق استفاده کند.

این پیکربندی می‌تواند چندین بار مشخص شود تا امکان گنجاندن چند مرجع یادداشت وجود داشته باشد. در این حالت، رفتاری مشابه ارسال چندین گزینه --[no-]notes[=] خواهد داشت. به این معنا که مقدار true یادداشت‌های پیش‌فرض را نشان می‌دهد، مقدار <ref> همچنین یادداشت‌های حاصل از آن مرجع یادداشت را نشان می‌دهد و مقدار false پیکربندی‌های قبلی را لغو کرده و یادداشتی نشان نمی‌دهد.

برای مثال،

[format]
        notes = true
        notes = foo
        notes = false
        notes = bar

تنها یادداشت‌های مربوط به refs/notes/bar را نشان خواهد داد.

format.mboxrd

یک مقدار بولی که فرمت مطمئن "mboxrd" را هنگام استفاده از --stdout برای اسکیپ کردن خطوط "^>+From " فعال می‌کند.

format.noprefix

در صورت تنظیم، هیچ پیشوند مبدأ یا مقصدی در وصله‌ها نشان داده نمی‌شود. این معادل گزینه diff.noprefix است که توسط git diff استفاده می‌شود (اما توسط format-patch رعایت نمی‌گردد). توجه داشته باشید که با تنظیم این متغیر، دریافت‌کننده وصله‌های تولیدی شما باید آن‌ها را با استفاده از گزینه -p0 اعمال کند.

fsck.<msg-id>

در طول fsck، ممکن است git مشکلاتی را در داده‌های قدیمی (legacy) پیدا کند که توسط نسخه‌های فعلی git تولید نمی‌شوند و در صورت تنظیم بودن transfer.fsckObjects روی شبکه ارسال نمی‌شدند. این ویژگی برای پشتیبانی از کار با مخازن قدیمی حاوی چنین داده‌هایی در نظر گرفته شده است.

تنظیم fsck.<msg-id> توسط git-fsck(1) خوانده می‌شود، اما برای پذیرش پوش‌های حاوی چنین داده‌هایی به جای آن receive.fsck.<msg-id> را تنظیم کنید، یا برای شبیه‌سازی (clone) یا واکشی (fetch) آن، fetch.fsck.<msg-id> را تنظیم نمایید.

بقیه مستندات برای اختصار در مورد fsck.* بحث می‌کند، اما همین موضوع در مورد متغیرهای متناظر receive.fsck.* و fetch.fsck.* نیز صدق می‌کند.

برخلاف متغیرهایی مانند color.ui و core.editor، متغیرهای receive.fsck.<msg-id> و fetch.fsck.<msg-id> در صورت عدم تنظیم، به پیکربندی fsck.<msg-id> رجوع نخواهند کرد (fall back نمی‌کنند). برای پیکربندی یکنواخت تنظیمات fsck در شرایط مختلف، هر سه آن‌ها باید روی مقادیر یکسان تنظیم شوند.

هنگامی که fsck.<msg-id> تنظیم شود، می‌توان با پیکربندی تنظیم fsck.<msg-id> خطاها را به هشدار و برعکس تبدیل کرد، جایی که <msg-id> همان شناسه پیام fsck است و مقدار یکی از error، warn یا ignore می‌باشد. برای راحتی، fsck پیشوند خطا/هشدار را با شناسه پیام مشخص می‌کند، به عنوان مثال "missingEmail: invalid author/committer line - missing email" به این معنی است که تنظیم fsck.missingEmail = ignore آن مشکل را پنهان خواهد کرد.

به‌طور کلی، بهتر است اشیاء مشکل‌دار موجود را با fsck.skipList فهرست کنید، به جای آنکه نوع خرابی‌های مشترک این اشیاء را برای نادیده گرفته شدن فهرست نمایید؛ چرا که انجام مورد دوم اجازه می‌دهد نمونه‌های جدید همان خرابی‌ها ناشناخته باقی بمانند.

تنظیم مقدار ناشناخته برای fsck.<msg-id> باعث متوقف شدن و خروج غیرعادی fsck می‌شود، اما انجام همین کار برای receive.fsck.<msg-id> و fetch.fsck.<msg-id> تنها باعث صدور هشدار توسط git خواهد شد.

برای مقادیر پشتیبانی‌شده <msg-id>، بخش Fsck Messages در git-fsck(1) را ببینید.

fsck.skipList

مسیر یک فهرست از نام‌های اشیاء (یعنی یک SHA-1 کامل و بدون اختصار در هر خط) که مشخص شده به‌گونه‌ای غیرمهلک خراب هستند و باید نادیده گرفته شوند. در نسخه‌های Git 2.20 و جدیدتر، توضیحات (#)، خطوط خالی، و هرگونه فاصله خالی ابتدایی و انتهایی نادیده گرفته می‌شوند. در نسخه‌های قدیمی‌تر، هر چیزی جز یک SHA-1 در هر خط با خطا مواجه خواهد شد.

این ویژگی زمانی مفید است که یک پروژه جاافتاده علی‌رغم کامیت‌های اولیه‌ای که حاوی خطاهای قابل چشم‌پوشی هستند (مانند آدرس‌های ایمیل نامعتبر ثبت‌کننده کامیت)، باید پذیرفته شود. توجه: اشیاء فاسد و آسیب‌دیده (corrupt objects) را نمی‌توان با این تنظیم نادیده گرفت.

مشابه fsck.<msg-id>، این متغیر دارای انواع متناظر receive.fsck.skipList و fetch.fsck.skipList است.

برخلاف متغیرهایی مانند color.ui و core.editor، متغیرهای receive.fsck.skipList و fetch.fsck.skipList در صورت عدم تنظیم، به پیکربندی fsck.skipList رجوع نمی‌کنند. برای پیکربندی یکنواخت تنظیمات fsck در شرایط مختلف، هر سه آن‌ها باید روی مقادیر یکسان تنظیم شوند.

نسخه‌های قدیمی‌تر Git (قبل از 2.20) مستند کرده بودند که فهرست نام‌های اشیاء باید مرتب شده باشد. این موضوع هرگز یک الزام نبود؛ نام‌های اشیاء می‌توانستند به هر ترتیبی ظاهر شوند، اما هنگام خواندن فهرست، برای اهداف پیاده‌سازی جستجوی دودویی داخلی که می‌توانست با فهرست از قبل مرتب‌شده کار کمتری انجام دهد، مرتب بودن فهرست ردیابی می‌شد. مگر اینکه فهرستی بسیار عظیم داشتید، دلیلی برای مرتب‌سازی اولیه فهرست وجود نداشت. پس از نسخه Git 2.20 پیاده‌سازی درهم‌سازی (hash) در عوض استفاده می‌شود، بنابراین اکنون دلیلی برای مرتب‌سازی اولیه فهرست وجود ندارد.

fsmonitor.allowRemote

به‌طور پیش‌فرض، دیمن fsmonitor از کار با مخازن متصل‌شده از طریق شبکه (network-mounted) خودداری می‌کند. تنظیم fsmonitor.allowRemote روی true این رفتار را بازنویسی می‌کند. تنها زمانی رعایت می‌شود که core.fsmonitor روی true تنظیم شده باشد.

fsmonitor.socketDir

این گزینه مخصوص Mac OS و Linux در صورت تنظیم، پوشه‌ای را مشخص می‌کند که سوکت دامنه یونیکس (Unix domain socket) مورد استفاده برای ارتباط بین دیمن fsmonitor و دستورات مختلف Git در آن ایجاد شود. این پوشه باید روی یک سیستم‌فایل بومی (native) قرار داشته باشد. تنها زمانی رعایت می‌شود که core.fsmonitor روی true تنظیم شده باشد.

gc.aggressiveDepth

پارامتر عمق (depth) مورد استفاده در الگوریتم فشرده‌سازی دلتا که توسط git gc --aggressive به کار می‌رود. مقدار پیش‌فرض آن 50 است، که پیش‌فرض گزینه --depth در زمان عدم استفاده از --aggressive می‌باشد.

برای جزئیات بیشتر مستندات مربوط به گزینه --depth در git-repack(1) را ببینید.

gc.aggressiveWindow

پارامتر اندازه پنجره مورد استفاده در الگوریتم فشرده‌سازی دلتا که توسط git gc --aggressive به کار می‌رود. مقدار پیش‌فرض آن 250 است، که اندازه پنجره‌ای بسیار تهاجمی‌تر از مقدار پیش‌فرض 10 برای --window است.

برای جزئیات بیشتر مستندات مربوط به گزینه --window در git-repack(1) را ببینید.

gc.auto

هنگامی که تقریباً بیش از این تعداد شیء مجزا (loose objects) در مخزن وجود داشته باشد، git gc --auto آن‌ها را بسته‌بندی (pack) می‌کند. برخی دستورات سطح بالا (Porcelain) از این دستور برای انجام گه‌گاه جمع‌آوری زباله سبک استفاده می‌کنند. مقدار پیش‌فرض 6700 است.

تنظیم این مقدار روی 0 نه تنها بسته‌بندی خودکار بر اساس تعداد اشیاء مجزا را غیرفعال می‌کند، بلکه هر روش شهودی دیگری را نیز که git gc --auto در غیر این صورت برای تشخیص وجود کار انجام‌دادنی استفاده می‌کرد (مانند gc.autoPackLimit)، غیرفعال می‌سازد.

gc.autoPackLimit

هنگامی که بیش از این تعداد بسته وجود داشته باشد که با فایل *.keep در مخزن علامت‌گذاری نشده‌اند، git gc --auto آن‌ها را در یک بسته بزرگ‌تر تجمیع می‌کند. مقدار پیش‌فرض 50 است. تنظیم آن روی 0 این قابلیت را غیرفعال می‌کند. تنظیم gc.auto روی 0 نیز این را غیرفعال خواهد کرد.

متغیر پیکربندی gc.bigPackThreshold در زیر را ببینید. در صورت استفاده، بر نحوه عملکرد محدودیت بسته‌بندی خودکار تأثیر می‌گذارد.

gc.autoDetach

کاری می‌کند که git gc --auto در صورت پشتیبانی سیستم، بلافاصله بازگردد و در پس‌زمینه اجرا شود. پیش‌فرض true است. این متغیر پیکربندی به عنوان جایگزین پشتیبان در صورت تنظیم نبودن maintenance.autoDetach عمل می‌کند.

gc.bigPackThreshold

اگر غیرصفر باشد، هنگام اجرای git gc تمام بسته‌های غیرکرافتی (non-cruft) بزرگ‌تر از این حد نگه‌داشته می‌شوند. این بسیار شبیه به --keep-largest-pack است با این تفاوت که تمام بسته‌های غیرکرافتی که به این حد آستانه می‌رسند نگه‌داشته می‌شوند، نه فقط بزرگ‌ترین بسته. پیش‌فرض صفر است. پسوندهای رایج واحد k، m یا g پشتیبانی می‌شوند.

توجه داشته باشید که اگر تعداد بسته‌های نگه‌داشته‌شده بیش از gc.autoPackLimit باشد، این متغیر پیکربندی نادیده گرفته می‌شود و تمام بسته‌ها به جز بسته پایه دوباره بسته‌بندی (repack) خواهند شد. پس از این، تعداد بسته‌ها باید به زیر gc.autoPackLimit برسد و gc.bigPackThreshold دوباره رعایت شود.

اگر مقدار حافظه تخمینی برای اجرای روان git repack در دسترس نباشد و gc.bigPackThreshold تنظیم نشده باشد، بزرگ‌ترین بسته نیز مستثنی خواهد شد (این معادل اجرای git gc با --keep-largest-pack است).

gc.writeCommitGraph

اگر true باشد، هنگام اجرای git-gc(1) فرآیند gc فایل commit-graph را بازنویسی خواهد کرد. هنگام استفاده از git gc --auto، در صورت نیاز به خانه‌تکانی و نگهداری (housekeeping)، نمودار کامیت به‌روزرسانی خواهد شد. پیش‌فرض true است. برای جزئیات به git-commit-graph(1) مراجعه کنید.

gc.logExpiry

اگر فایل gc.log وجود داشته باشد، git gc --auto به جای اجرا، محتوای آن را چاپ کرده و با وضعیت صفر خارج می‌شود، مگر اینکه عمر آن فایل بیشتر از gc.logExpiry باشد. پیش‌فرض "1.day" است. برای روش‌های بیشتر تعیین مقدار آن، به gc.pruneExpire مراجعه کنید.

gc.packRefs

اجرای git pack-refs در یک مخزن، آن را برای نسخه‌های Git قبل از 1.5.1.2 روی پروتکل‌های انتقال ساده (dumb transports) مانند HTTP غیرقابل کلون می‌کند. این متغیر تعیین می‌کند که آیا git gc دستور git pack-refs را اجرا کند یا خیر. می‌تواند روی notbare تنظیم شود تا در تمام مخازن غیرلخت (non-bare) فعال گردد یا می‌تواند روی یک مقدار بولی تنظیم شود. پیش‌فرض true است.

gc.cruftPacks

ذخیره اشیاء غیرقابل‌دسترس در یک بسته کرافت (cruft pack؛ نگاه کنید به git-repack(1)) به جای اشیاء مجزا (loose objects). پیش‌فرض true است.

gc.maxCruftSize

محدود کردن اندازه بسته‌های کرافت جدید هنگام بسته‌بندی مجدد. در صورت تعیین هم‌زمان با --max-cruft-size، گزینه خط فرمان اولویت دارد. گزینه --max-cruft-size در git-repack(1) را ببینید.

gc.pruneExpire

هنگامی که git gc اجرا می‌شود، دستور prune --expire 2.weeks.ago (و در صورت استفاده از بسته‌های کرافت از طریق gc.cruftPacks یا --cruft، دستور repack --cruft --cruft-expiration 2.weeks.ago) را فراخوانی می‌کند. مهلت مقرر (grace period) را با این متغیر پیکربندی تغییر دهید. مقدار "now" می‌تواند برای غیرفعال کردن این مهلت و پاک‌سازی فوری اشیاء غیرقابل‌دسترس استفاده شود، یا "never" می‌تواند برای متوقف کردن کامل پاک‌سازی استفاده گردد. این ویژگی به جلوگیری از خرابی داده‌ها در زمانی که git gc هم‌زمان با فرآیند دیگری در حال نوشتن روی مخزن اجرا می‌شود کمک می‌کند؛ بخش "NOTES" در git-gc(1) را ببینید.

gc.worktreePruneExpire

هنگامی که git gc اجرا می‌شود، دستور git worktree prune --expire 3.months.ago را فراخوانی می‌کند. این متغیر پیکربندی می‌تواند برای تعیین مهلت مقرر متفاوتی استفاده شود. مقدار "now" ممکن است برای غیرفعال کردن مهلت مقرر و هرس فوری $GIT_DIR/worktrees استفاده شود، یا "never" برای متوقف کردن پاک‌سازی به کار رود.

gc.reflogExpire, gc.<pattern>.reflogExpire

دستور git reflog expire مدخل‌های رف‌لاگ (reflog) قدیمی‌تر از این زمان را حذف می‌کند؛ پیش‌فرض 90 روز است. مقدار "now" تمام مدخل‌ها را فوراً منقضی می‌کند، و "never" انقضا را به‌طور کامل متوقف می‌سازد. با قرار دادن "<pattern>" (مثلاً "refs/stash") در وسط، این تنظیم تنها بر مراجعی که با <pattern> مطابقت دارند اعمال می‌شود.

gc.reflogExpireUnreachable, gc.<pattern>.reflogExpireUnreachable

دستور git reflog expire مدخل‌های رف‌لاگ قدیمی‌تر از این زمان را که از نوک (tip) فعلی قابل دسترس نیستند حذف می‌کند؛ پیش‌فرض 30 روز است. مقدار "now" تمام مدخل‌ها را فوراً منقضی می‌کند، و "never" انقضا را به‌طور کامل متوقف می‌سازد. با قرار دادن "<pattern>" (مثلاً "refs/stash") در وسط، تنظیم تنها بر مراجعی که با <pattern> مطابقت دارند اعمال می‌شود.

این نوع مدخل‌ها معمولاً در نتیجه استفاده از git commit --amend یا git rebase ایجاد می‌شوند و کامیت‌های قبل از رخ دادن اصلاح (amend) یا ری‌بیس هستند. از آنجا که این تغییرات بخشی از پروژه فعلی نیستند، بیشتر کاربران تمایل دارند آن‌ها را زودتر منقضی کنند، به همین دلیل پیش‌فرض تهاجمی‌تر از gc.reflogExpire است.

gc.recentObjectsHook

هنگام بررسی اینکه آیا یک شیء حذف شود یا خیر (چه هنگام تولید یک بسته کرافت یا ذخیره اشیاء غیرقابل‌دسترس به‌صورت مجزا)، از شل برای اجرای دستور(های) مشخص‌شده استفاده می‌کند. خروجی آن‌ها به عنوان شناسه‌های اشیائی تفسیر می‌شود که Git صرف‌نظر از سن واقعی‌شان، آن‌ها را به عنوان "اخیر" (recent) در نظر می‌گیرد. با در نظر گرفتن mtime آن‌ها به عنوان "اکنون"، هر شیء (و نوادگان آن) ذکرشده در خروجی، صرف‌نظر از سن واقعی‌شان نگه‌داشته خواهند شد.

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

gc.repackFilter

هنگام بسته‌بندی مجدد (repack)، از فیلتر مشخص‌شده برای انتقال اشیاء خاص به یک فایل بسته جداگانه استفاده می‌کند. گزینه --filter=<filter-spec> در git-repack(1) را ببینید.

gc.repackFilterTo

هنگام بسته‌بندی مجدد و استفاده از یک فیلتر (نگاه کنید به gc.repackFilter)، مکان مشخص‌شده برای ایجاد فایل بسته‌ای که شامل اشیاء فیلترشده است استفاده خواهد شد. هشدار: مکان مشخص‌شده باید قابل دسترس باشد، برای مثال با استفاده از مکانیزم Git alternates، در غیر این صورت ممکن است مخزن توسط Git فاسد در نظر گرفته شود چرا که ممکن است نتواند به اشیاء موجود در آن فایل بسته دسترسی پیدا کند. گزینه --filter-to=<dir> در git-repack(1) و بخش objects/info/alternates از gitrepository-layout(5) را ببینید.

gc.rerereResolved

ثبت‌های ادغام با تعارضی که قبلاً حل کرده‌اید، هنگام اجرای git rerere gc برای این تعداد روز نگه‌داری می‌شوند. همچنین می‌توانید از عبارات خواناتر برای انسان مانند "1.month.ago" و غیره استفاده کنید. پیش‌فرض 60 روز است. به git-rerere(1) مراجعه کنید.

gc.rerereUnresolved

ثبت‌های ادغام با تعارضی که حل نکرده‌اید، هنگام اجرای git rerere gc برای این تعداد روز نگه‌داری می‌شوند. همچنین می‌توانید از عبارات خواناتر برای انسان مانند "1.month.ago" و غیره استفاده کنید. پیش‌فرض 15 روز است. به git-rerere(1) مراجعه کنید.

gitcvs.commitMsgAnnotation

این رشته را به انتهای هر پیام کامیت پیوست می‌کند. برای غیرفعال کردن این ویژگی، آن را روی رشته خالی تنظیم کنید. پیش‌فرض "via git-CVS emulator" است.

gitcvs.enabled

مشخص می‌کند که آیا رابط سرور CVS برای این مخزن فعال است یا خیر. به git-cvsserver(1) مراجعه کنید.

gitcvs.logFile

مسیر فایل لاگی که رابط کاربری سرور CVS در آن خب... موارد مختلف را لاگ می‌کند. به git-cvsserver(1) مراجعه کنید.

gitcvs.usecrlfattr

اگر true باشد، سرور ویژگی‌های تبدیل پایان خط را برای فایل‌ها جستجو می‌کند تا حالت‌های -k مورد استفاده را تعیین کند. اگر این مشخصه‌ها Git را وادار کنند فایلی را به عنوان متنی در نظر بگیرد، حالت -k خالی رها می‌شود تا کلاینت‌های CVS با آن به عنوان متن رفتار کنند. اگر آن‌ها تبدیل متن را سرکوب کنند، فایل با حالت -kb تنظیم می‌شود که هرگونه دستکاری خطوط جدید را که کلاینت ممکن است در غیر این صورت انجام دهد، سرکوب می‌کند. اگر مشخصه‌ها اجازه تعیین نوع فایل را ندهند، gitcvs.allBinary استفاده می‌شود. به gitattributes(5) مراجعه کنید.

gitcvs.allBinary

اگر gitcvs.usecrlfattr حالت صحیح -kb را تعیین نکند، این متغیر به کار می‌رود. اگر true باشد، تمام فایل‌های تعیین‌تکلیف‌نشده در حالت -kb به کلاینت ارسال می‌شوند. این کار باعث می‌شود کلاینت با آن‌ها به عنوان فایل‌های باینری رفتار کند، که هرگونه دستکاری خطوط جدید را سرکوب می‌کند. از طرف دیگر، اگر روی "guess" تنظیم شود، محتویات فایل برای تصمیم‌گیری در مورد باینری بودن آن بررسی می‌شود، مشابه core.autocrlf.

gitcvs.dbName

پایگاه داده‌ای که توسط git-cvsserver برای کش کردن اطلاعات بازبینی برگرفته از مخزن Git استفاده می‌شود. معنی دقیق به درایور پایگاه داده استفاده‌شده بستگی دارد؛ برای SQLite (که درایور پیش‌فرض است) این یک نام فایل است. از جایگزینی متغیرها پشتیبانی می‌کند (برای جزئیات به git-cvsserver(1) مراجعه کنید). نباید شامل نقطه‌ویرگول (;) باشد. پیش‌فرض: %Ggitcvs.%m.sqlite

gitcvs.dbDriver

درایور Perl DBI استفاده‌شده. در اینجا می‌توانید هر درایور موجود را برای این منظور مشخص کنید، اما ممکن است کار نکند. نرم‌افزار git-cvsserver با DBD::SQLite آزمایش شده، گزارش شده که با DBD::Pg کار می‌کند، و گزارش شده که با DBD::mysql کار نمی‌کند. ویژگی آزمایشی. نباید شامل دو دونقطه (:) باشد. پیش‌فرض: SQLite. به git-cvsserver(1) مراجعه کنید.

gitcvs.dbUser, gitcvs.dbPass

کاربر و رمز عبور پایگاه داده. تنها در صورتی مفید است که gitcvs.dbDriver تنظیم شده باشد، زیرا SQLite مفهومی از کاربران و/یا رمزهای عبور پایگاه داده ندارد. gitcvs.dbUser از جایگزینی متغیرها پشتیبانی می‌کند (برای جزئیات به git-cvsserver(1) مراجعه کنید).

gitcvs.dbTableNamePrefix

پیشوند نام جداول پایگاه داده. به نام تمام جداول پایگاه داده مورد استفاده اضافه می‌شود و امکان استفاده از یک پایگاه داده واحد برای چندین مخزن را فراهم می‌کند. از جایگزینی متغیر پشتیبانی می‌کند (برای جزئیات به git-cvsserver(1) مراجعه کنید). هر کاراکتر غیرالفبایی با زیرخط (underscore) جایگزین خواهد شد.

تمام متغیرهای gitcvs به جز gitcvs.usecrlfattr و gitcvs.allBinary را می‌توان به عنوان gitcvs.<access_method>.<varname> نیز مشخص کرد (که در آن access_method یکی از مقادیر "ext" و "pserver" است) تا فقط برای روش دسترسی مشخص‌شده اعمال شوند.

gitweb.category, gitweb.description, gitweb.owner, gitweb.url

برای توضیحات به gitweb(1) مراجعه کنید.

gitweb.avatar, gitweb.blame, gitweb.grep, gitweb.highlight, gitweb.patches, gitweb.pickaxe, gitweb.remote_heads, gitweb.showSizes, gitweb.snapshot

برای توضیحات به gitweb.conf(5) مراجعه کنید.

gpg.program

مسیر برنامه‌ای که باید هنگام ایجاد یا اعتبارسنجی امضای PGP به جای "gpg" استفاده شود. این برنامه باید از همان رابط خط فرمان GPG پشتیبانی کند، به این صورت که برای اعتبارسنجی یک امضای مجزا (detached signature)، دستور "gpg --verify $signature - <$file" اجرا می‌شود، و انتظار می‌رود برنامه با خروج با کد 0 امضای معتبر را اعلام کند. برای تولید یک امضای مجزای محافظت‌شده با زره اسکی (ASCII-armored)، ورودی استاندارد "gpg -bsau $key" با محتوایی که باید امضا شود تغذیه می‌گردد و انتظار می‌رود برنامه نتیجه را به خروجی استاندارد خود بفرستد.

gpg.format

فرمت کلید مورد استفاده هنگام امضا با --gpg-sign را مشخص می‌کند. پیش‌فرض "openpgp" است. سایر مقادیر مجاز عبارتند از "x509" و "ssh".

برای فرمت امضا که بر اساس gpg.format انتخاب‌شده متفاوت است، به gitformat-signature(5) مراجعه کنید.

gpg.<format>.program

از این برای سفارشی‌سازی برنامه استفاده‌شده برای فرمت امضایی که انتخاب کرده‌اید استفاده کنید (نگاه کنید به gpg.program و gpg.format). gpg.program هنوز می‌تواند به عنوان یک مترادف قدیمی برای gpg.openpgp.program استفاده شود. مقدار پیش‌فرض برای gpg.x509.program برابر "gpgsm" و برای gpg.ssh.program برابر "ssh-keygen" است.

gpg.minTrustLevel

حداقل سطح اعتماد را برای اعتبارسنجی امضا مشخص می‌کند. اگر این گزینه تنظیم نشده باشد، اعتبارسنجی امضا برای عملیات‌های ادغام نیازمند کلیدی با حداقل سطح اعتماد marginal است. سایر عملیات‌هایی که اعتبارسنجی امضا را انجام می‌دهند به کلیدی با حداقل اعتماد undefined نیاز دارند. تنظیم این گزینه سطح اعتماد مورد نیاز را برای تمام عملیات‌ها بازنویسی می‌کند. مقادیر پشتیبانی‌شده به ترتیب صعودی اهمیت:
•undefined
•never
•marginal
•fully
•ultimate

gpg.ssh.defaultKeyCommand

این دستور زمانی اجرا می‌شود که user.signingkey تنظیم نشده باشد و امضای ssh درخواست شود. در صورت خروج موفق، انتظار می‌رود یک کلید عمومی معتبر ssh که با پیشوند key:: شروع می‌شود در خط اول خروجی آن باشد. این امر امکان استفاده از اسکریپتی را برای جستجوی پویای کلید عمومی صحیح فراهم می‌کند، زمانی که پیکربندی ایستا برای user.signingKey عملی نباشد؛ برای مثال هنگامی که کلیدها یا گواهی‌های SSH به‌طور مکرر تعویض (rotate) می‌شوند یا انتخاب کلید مناسب به عوامل خارجی وابسته است که برای git ناشناخته هستند.

gpg.ssh.allowedSignersFile

فایلی شامل کلیدهای عمومی ssh که مایل به اعتماد به آن‌ها هستید. فایل شامل یک یا چند خط از هویت‌ها (principals) و به دنبال آن یک کلید عمومی ssh است. به عنوان مثال: user1@example.com,user2@example.com ssh-rsa AAAAX1... برای جزئیات به بخش "ALLOWED SIGNERS" در ssh-keygen(1) مراجعه کنید. هویت (principal) فقط برای شناسایی کلید استفاده می‌شود و هنگام اعتبارسنجی امضا در دسترس است.

برخلاف gpg، در SSH مفهومی از سطوح اعتماد وجود ندارد. برای تمایز بین امضاهای معتبر و امضاهای قابل اعتماد، سطح اعتماد اعتبارسنجی امضا در صورتی که کلید عمومی در allowedSignersFile وجود داشته باشد روی fully تنظیم می‌شود. در غیر این صورت سطح اعتماد undefined خواهد بود و دستور git verify-commit/tag ناموفق خواهد شد.

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

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

از OpenSSH 8.8 به بعد، این فایل امکان تعیین طول عمر کلید را با استفاده از گزینه‌های valid-after و valid-before فراهم می‌کند. اگر کلید امضاکننده در زمان ایجاد امضا معتبر بوده باشد، Git امضاها را معتبر علامت‌گذاری می‌کند. این به کاربران امکان می‌دهد کلید امضا را بدون باطل کردن تمام امضاهای قبلی تغییر دهند.

استفاده از یک کلید CA مربوط به SSH با گزینه cert-authority (نگاه کنید به بخش "CERTIFICATES" در ssh-keygen(1)) نیز معتبر است.

gpg.ssh.revocationFile

یک SSH KRL یا فهرستی از کلیدهای عمومی باطل‌شده (بدون پیشوند هویت). برای جزئیات به ssh-keygen(1) مراجعه کنید. اگر یک کلید عمومی در این فایل پیدا شود، همیشه دارای سطح اعتماد "never" در نظر گرفته می‌شود و امضاها نامعتبر نمایش داده خواهند شد.

grep.lineNumber

اگر روی true تنظیم شود، گزینه -n را به‌طور پیش‌فرض فعال می‌کند.

grep.column

اگر روی true تنظیم شود، گزینه --column را به‌طور پیش‌فرض فعال می‌کند.

grep.patternType

رفتار پیش‌فرض تطبیق الگو را تنظیم می‌کند. استفاده از مقدار basic، extended، fixed یا perl به ترتیب گزینه --basic-regexp، --extended-regexp، --fixed-strings یا --perl-regexp را فعال می‌کند، در حالی که مقدار default از گزینه grep.extendedRegexp برای انتخاب بین basic و extended استفاده خواهد کرد.

grep.extendedRegexp

اگر روی true تنظیم شود، گزینه --extended-regexp را به‌طور پیش‌فرض فعال می‌کند. این گزینه زمانی که گزینه grep.patternType روی مقداری غیر از default تنظیم شده باشد، نادیده گرفته می‌شود.

grep.threads

تعداد نخ‌های پردازشی (worker threads) دستور grep که باید استفاده شوند. اگر تنظیم نشود (یا روی 0 تنظیم شود)، Git به اندازه تعداد هسته‌های منطقی موجود از نخ‌ها استفاده خواهد کرد.

grep.fullName

اگر روی true تنظیم شود، گزینه --full-name را به‌طور پیش‌فرض فعال می‌کند.

grep.fallbackToNoIndex

اگر روی true تنظیم شود، در صورتی که git grep خارج از یک مخزن git اجرا گردد، به git grep --no-index رجوع خواهد کرد. پیش‌فرض false است.

gui.commitMsgWidth

عرض پنجره پیام کامیت را در git-gui(1) تعیین می‌کند. پیش‌فرض "75" است.

gui.diffContext

مشخص می‌کند که چه تعداد خط بافت (context lines) باید در فراخوانی‌های diff ایجادشده توسط git-gui(1) استفاده شود. پیش‌فرض "5" است.

gui.displayUntracked

مشخص می‌کند که آیا git-gui(1) فایل‌های ردیابی‌نشده (untracked) را در فهرست فایل‌ها نمایش دهد یا خیر. پیش‌فرض "true" است.

gui.encoding

رمزگذاری کاراکتر پیش‌فرض را برای نمایش محتوای فایل در git-gui(1) و gitk(1) مشخص می‌کند. این مقدار می‌تواند با تنظیم صفت encoding برای فایل‌های مربوطه بازنویسی شود (نگاه کنید به gitattributes(5)). اگر این گزینه تنظیم نشود، ابزارها به کدگذاری محلی (locale) بازمی‌گردند.

gui.matchTrackingBranch

مشخص می‌کند که آیا شاخه‌های جدید ایجادشده با git-gui(1) به‌طور پیش‌فرض باید شاخه‌های ریموت با نام‌های مطابقت‌دار را ردیابی کنند یا خیر. پیش‌فرض: "false".

gui.newBranchTemplate

به عنوان نام پیشنهادی هنگام ایجاد شاخه‌های جدید با استفاده از git-gui(1) استفاده می‌شود.

gui.pruneDuringFetch

مقدار "true" اگر git-gui(1) باید هنگام انجام واکشی (fetch)، شاخه‌های ردیابی ریموت را هرس (prune) کند. مقدار پیش‌فرض "false" است.

gui.trustmtime

مشخص می‌کند که آیا git-gui(1) باید به برچسب زمانی تغییر فایل (modification timestamp) اعتماد کند یا خیر. به‌طور پیش‌فرض به برچسب‌های زمانی اعتماد نمی‌شود.

gui.spellingDictionary

لغت‌نامه مورد استفاده برای غلط‌گیری املایی پیام‌های کامیت در git-gui(1) را مشخص می‌کند. در صورت تنظیم روی "none"، بررسی املا خاموش می‌شود.

gui.fastCopyBlame

اگر true باشد، git gui blame برای تشخیص مکان اصلی به جای -C -C از -C استفاده می‌کند. این کار در مخازن بسیار بزرگ، عمل blame را به بهای تشخیص کمتر رونوشت‌ها (copy detection)، به‌طور چشمگیری سریع‌تر می‌کند.

gui.copyBlameThreshold

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

gui.blamehistoryctx

شعاع بافت تاریخچه را بر حسب روز برای نمایش در gitk(1) برای کامیت انتخاب‌شده مشخص می‌کند، زمانی که آیتم منوی Show History Context از git gui blame فراخوانی شود. اگر این متغیر روی صفر تنظیم شود، کل تاریخچه نشان داده می‌شود.

gui.GCWarning

مشخص می‌کند که آیا git-gui(1) هنگامی که git تعداد زیادی شیء مجزا را در مخزن شناسایی می‌کند، باید درخواست جمع‌آوری زباله را نمایش دهد یا خیر. مقدار پیش‌فرض "true" است.

guitool.<name>.cmd

خط فرمان شل را برای اجرا در هنگام فراخوانی مورد مربوطه از منوی Tools در git-gui(1) مشخص می‌کند. این گزینه برای هر ابزاری الزامی است. دستور از ریشه پوشه کاری اجرا می‌شود و در محیط، نام ابزار را به عنوان GIT_GUITOOL، نام فایل انتخاب‌شده فعلی را به عنوان FILENAME، و نام شاخه فعلی را به عنوان CUR_BRANCH دریافت می‌کند (اگر هد جداشده [detached] باشد، CUR_BRANCH خالی است).

guitool.<name>.needsFile

ابزار را تنها در صورتی اجرا می‌کند که یک تفاوت (diff) در رابط کاربری انتخاب شده باشد. این تضمین می‌کند که FILENAME خالی نباشد.

guitool.<name>.noConsole

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

guitool.<name>.noRescan

پس از اتمام اجرای ابزار، پوشه کاری را برای تغییرات دوباره پویش (rescan) نمی‌کند.

guitool.<name>.confirm

قبل از اجرای واقعی ابزار، یک کادر گفتگوی تأیید را نمایش می‌دهد.

guitool.<name>.argPrompt

یک آرگومان رشته‌ای از کاربر درخواست می‌کند و آن را از طریق متغیر محیطی ARGS به ابزار ارسال می‌نماید. از آنجا که درخواست آرگومان متضمن تأیید است، در صورت فعال بودن این گزینه، گزینه confirm هیچ اثری ندارد. اگر گزینه روی true، yes یا 1 تنظیم شده باشد، کادر گفتگو از یک اعلان عمومی توکار استفاده می‌کند؛ در غیر این صورت مقدار دقیق متغیر به کار می‌رود.

guitool.<name>.revPrompt

یک بازنگری (revision) معتبر واحد را از کاربر درخواست می‌کند و متغیر محیطی REVISION را تنظیم می‌نماید. از جنبه‌های دیگر این گزینه شبیه به argPrompt است و می‌تواند همراه با آن استفاده شود.

guitool.<name>.revUnmerged

تنها شاخه‌های ادغام‌نشده را در زیرگفتگوی revPrompt نشان می‌دهد. این برای ابزارهای مشابه merge یا rebase مفید است، اما برای مواردی مانند checkout یا reset کاربرد ندارد.

guitool.<name>.title

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

guitool.<name>.prompt

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

help.browser

مرورگری را مشخص می‌کند که برای نمایش راهنما در قالب web استفاده خواهد شد. به git-help(1) مراجعه کنید.

help.format

قالب پیش‌فرض راهنمای استفاده‌شده توسط git-help(1) را بازنویسی می‌کند. مقادیر man، info، web و html پشتیبانی می‌شوند. man پیش‌فرض است. web و html یکسان هستند.

help.autoCorrect

اگر git غلط‌های املایی را تشخیص دهد و بتواند دقیقاً یک دستور معتبر شبیه به خطا را شناسایی کند، سعی می‌کند دستور صحیح را پیشنهاد دهد یا حتی پیشنهاد را به‌طور خودکار اجرا نماید. مقادیر ممکن برای پیکربندی عبارتند از:
•0، "false"، "off"، "no"، "show": نمایش دستور پیشنهادی (پیش‌فرض).
•1، "true"، "on"، "yes"، "immediate": اجرای فوری دستور پیشنهادی.
•عدد مثبت > 1: اجرای دستور پیشنهادی پس از دهم‌ثانیه‌های مشخص‌شده (0.1 ثانیه).
•"never": هیچ دستور پیشنهادی را اجرا یا نمایش ندهد.
•"prompt": پیشنهاد را نشان داده و برای اجرای دستور تأییدیه بخواهد.

help.htmlPath

مسیری را مشخص می‌کند که مستندات HTML در آن قرار دارند. مسیرهای سیستم‌فایل و نشانی‌های وب (URLs) پشتیبانی می‌شوند. هنگامی که راهنما در قالب web نمایش داده می‌شود، صفحات HTML با این مسیر پیشوند خواهند شد. پیش‌فرض این مسیر مستندات مربوط به نصب Git شما است.

hook.<friendly-name>.command

دستوری که برای hook.<friendly-name> باید اجرا شود. <friendly-name> نامی یکتاست که این قلاب را شناسایی می‌کند. رویدادهای قلابی که دستور را فراخوانی می‌کنند با hook.<friendly-name>.event پیکربندی می‌شوند. این مقدار می‌تواند یک مسیر اجرایی یا یک تک‌خطی شل (shell oneliner) باشد. اگر بیش از یک مقدار برای همان <friendly-name> مشخص شود، تنها آخرین مقدار تجزیه‌شده استفاده می‌شود. به git-hook(1) مراجعه کنید.

hook.<friendly-name>.event

رویدادهای قلاب که hook.<friendly-name> را فعال می‌کنند. این مقدار نام یک رویداد قلاب مانند "pre-commit" یا "update" است. (برای فهرست کامل رویدادهای قلاب به githooks(5) مراجعه کنید.) در رویداد مشخص‌شده، دستور مرتبط hook.<friendly-name>.command اجرا می‌شود. این یک کلید چندمقداری است. برای اجرای hook.<friendly-name> روی چندین رویداد، کلید را بیش از یک بار مشخص کنید. یک مقدار خالی فهرست رویدادها را بازنشانی می‌کند و رویدادهای تعریف‌شده قبلی را برای hook.<friendly-name> پاک می‌نماید. به git-hook(1) مراجعه کنید.

نام <friendly-name> نباید مشابه نام یک رویداد قلاب شناخته‌شده باشد (برای مثال از hook.pre-commit.event استفاده نکنید). استفاده از نام یک رویداد شناخته‌شده به عنوان friendly-name یک خطای مهلک است زیرا باعث ایجاد ابهام با hook.<event>.enabled و hook.<event>.jobs می‌شود. برای نام‌های رویداد ناشناخته، زمانی که <friendly-name> با مقدار رویداد مطابقت داشته باشد یک هشدار صادر می‌شود.

hook.<friendly-name>.enabled

مشخص می‌کند که آیا قلاب hook.<friendly-name> فعال است یا خیر. پیش‌فرض true است. برای غیرفعال کردن قلاب بدون حذف پیکربندی آن، روی false تنظیم کنید. این به‌ویژه زمانی مفید است که قلاب در یک فایل پیکربندی سیستمی یا سراسری تعریف شده باشد و نیاز باشد برای یک مخزن خاص غیرفعال گردد. به git-hook(1) مراجعه کنید.

hook.<friendly-name>.parallel

مشخص می‌کند که آیا قلاب hook.<friendly-name> ممکن است به صورت موازی با سایر قلاب‌ها برای همان رویداد اجرا شود یا خیر. پیش‌فرض false است. تنها زمانی روی true تنظیم کنید که اسکریپت قلاب برای اجرای هم‌روند با سایر قلاب‌ها برای همان رویداد ایمن باشد. اگر هر قلابی برای یک رویداد این گزینه را روی true تنظیم نکرده باشد، تمام قلاب‌ها برای آن رویداد صرف‌نظر از hook.jobs به صورت متوالی اجرا می‌شوند. فقط قلاب‌های پیکربندی‌شده (نام‌گذاری‌شده) نیاز به اعلام این مورد دارند. قلاب‌های سنتی موجود در پوشه hooks نیازی به این کار ندارند و زمانی که تعداد کارهای مؤثر بزرگ‌تر از 1 باشد به صورت موازی اجرا می‌شوند. به git-hook(1) مراجعه کنید.

hook.<event>.enabled

کلید برای فعال یا غیرفعال کردن تمام قلاب‌ها برای رویداد قلاب <event> است. هنگامی که روی false تنظیم شود، هیچ قلابی برای آن رویداد اجرا نمی‌شود، صرف‌نظر از هرگونه تنظیمات اختصاصی hook.<friendly-name>.enabled برای هر قلاب. مقدار پیش‌فرض true است. رجوع کنید به git-hook(1).

نکته در مورد نام‌گذاری: <event> باید نام رویداد باشد (مثلاً pre-commit)، نه نام دوستانه (friendly-name) قلاب. از آنجا که استفاده از یک نام رویداد شناخته‌شده به عنوان friendly-name مجاز نیست (ببینید hook.<friendly-name>.event در بالا)، هیچ ابهامی بین تنظیمات .enabled در سطح رویداد و در سطح هر قلاب برای رویدادهای شناخته‌شده وجود ندارد. برای رویدادهای ناشناخته، اگر یک friendly-name برخلاف هشدار با نام رویداد مطابقت داشته باشد، .enabled تنها به عنوان تنظیم اختصاصی هر قلاب در نظر گرفته می‌شود.

hook.<event>.jobs

مشخص می‌کند چه تعداد قلاب می‌توانند به طور هم‌زمان برای رویداد قلاب <event> اجرا شوند (مثلاً hook.post-receive.jobs = 4). مقدار hook.jobs را برای این رویداد خاص بازنویسی می‌کند. همان محدودیت‌های موازی‌سازی اعمال می‌شوند: این تنظیم هیچ تاثیری ندارد مگر آنکه تمام قلاب‌های پیکربندی‌شده برای آن رویداد دارای hook.<friendly-name>.parallel تنظیم‌شده روی true باشند. مقدار را روی -1 تنظیم کنید تا از تعداد هسته‌های موجود CPU استفاده شود. باید یک عدد صحیح مثبت یا -1 باشد؛ مقدار صفر همراه با یک هشدار رد می‌شود. رجوع کنید به git-hook(1).

نکته در مورد نام‌گذاری: هرچند این کلید شبیه به hook.<friendly-name>.* (یک تنظیم اختصاصی هر قلاب) است، <event> باید نام رویداد باشد، نه نام دوستانه قلاب. جزء کلید به صورت تحت‌اللفظی ذخیره می‌شود و در زمان اجرا بر اساس نام رویداد و بدون هیچ ترجمه‌ای بین این دو فضای نام جستجو می‌شود. کلیدی مانند hook.my-hook.jobs تحت "my-hook" ذخیره می‌شود اما جستجو در زمان اجرا از نام رویداد (مثلاً "post-receive") استفاده می‌کند، بنابراین hook.my-hook.jobs حتی در صورت ثبت بودن my-hook برای آن رویداد، بدون هشدار نادیده گرفته می‌شود. هنگام تنظیم hook.<event>.jobs از hook.post-receive.jobs یا هر نام رویداد معتبر دیگری استفاده کنید.

hook.jobs

مشخص می‌کند چه تعداد قلاب می‌توانند در طول اجرای موازی قلاب‌ها به طور هم‌زمان اجرا شوند. در صورت عدم تعیین، مقدار پیش‌فرض ۱ (اجرای ترتیبی) است. برای استفاده از تعداد هسته‌های موجود CPU، آن را روی -1 تنظیم کنید. می‌تواند بر مبنای هر رویداد با hook.<event>.jobs بازنویسی شود. برخی قلاب‌ها صرف‌نظر از این تنظیم همیشه به صورت ترتیبی اجرا می‌شوند، زیرا روی داده‌های مشترک عمل می‌کنند و نمی‌توانند با اطمینان موازی شوند:

applypatch-msg, prepare-commit-msg, commit-msg

یک فایل پیام ثبت را دریافت می‌کنند و ممکن است در همان جا آن را بازنویسی کنند.

pre-commit, post-checkout, push-to-checkout, post-commit

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

این تنظیم هیچ اثری ندارد مگر آنکه تمام قلاب‌های پیکربندی‌شده برای آن رویداد، hook.<friendly-name>.parallel را روی true تنظیم کرده باشند.

برای قلاب‌های pre-push که به طور عادی stdout و stderr را مجزا نگه می‌دارند، تنظیم این مقدار به بیش از ۱ (یا ارسال -j) باعث ادغام خروجی استاندارد در خطای استاندارد می‌شود تا تفکیک موازی خروجی‌ها به درستی صورت گیرد.

http.proxy

پروکسی HTTP را بازنویسی می‌کند، که معمولاً با استفاده از متغیرهای محیطی http_proxy, https_proxy, و all_proxy پیکربندی می‌شود (رجوع کنید به curl(1)). علاوه بر نحو قابل فهم برای curl، امکان تعیین یک رشته پروکسی با نام کاربری اما بدون گذرواژه وجود دارد که در این حالت git تلاش می‌کند به همان شیوه‌ای که برای سایر اعتبارنامه‌ها عمل می‌کند، گذرواژه‌ای به دست آورد. برای اطلاعات بیشتر gitcredentials(7) را ببینید. بنابراین ساختار نگارش به صورت [protocol://][user[:password]@]proxyhost[:port][/path] است. این مقدار می‌تواند برای هر ریموت بازنویسی شود؛ ببینید remote.<name>.proxy

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

http.proxyAuthMethod

روشی را تعیین می‌کند که با آن احراز هویت در برابر پروکسی HTTP انجام شود. این تنها در صورتی اعمال می‌شود که رشته پروکسی پیکربندی‌شده حاوی بخش نام کاربری باشد (یعنی به فرم user@host یا user@host:port باشد). این می‌تواند برای هر ریموت بازنویسی شود؛ ببینید remote.<name>.proxyAuthMethod. هر دو می‌توانند توسط متغیر محیطی GIT_HTTP_PROXY_AUTHMETHOD بازنویسی شوند. مقادیر ممکن عبارتند از:
•anyauth - انتخاب خودکار یک روش احراز هویت مناسب. فرض بر این است که پروکسی به یک درخواست احراز هویت‌نشده با کد وضعیت 407 و یک یا چند سرآیند Proxy-authenticate با روش‌های احراز هویت پشتیبانی‌شده پاسخ می‌دهد. این مقدار پیش‌فرض است.
•basic - احراز هویت HTTP Basic
•digest - احراز هویت HTTP Digest؛ این روش از ارسال گذرواژه به صورت متن آشکار به پروکسی جلوگیری می‌کند
•negotiate - احراز هویت GSS-Negotiate (مقایسه کنید با گزینه --negotiate در curl(1))
•ntlm - احراز هویت NTLM (مقایسه کنید با گزینه --ntlm در curl(1))

http.proxySSLCert

مسیر فایلی که یک گواهی کلاینت را برای احراز هویت در برابر یک پروکسی HTTPS ذخیره می‌کند. می‌تواند توسط متغیر محیطی GIT_PROXY_SSL_CERT بازنویسی شود.

http.proxySSLKey

مسیر فایلی که یک کلید خصوصی را برای احراز هویت در برابر یک پروکسی HTTPS ذخیره می‌کند. می‌تواند توسط متغیر محیطی GIT_PROXY_SSL_KEY بازنویسی شود.

http.proxySSLCertPasswordProtected

درخواست گذرواژه Git برای گواهی SSL پروکسی را فعال می‌کند. در غیر این صورت، اگر گواهی یا کلید خصوصی رمزنگاری شده باشد، OpenSSL ممکن است مکرراً از کاربر درخواست گذرواژه کند. می‌تواند توسط متغیر محیطی GIT_PROXY_SSL_CERT_PASSWORD_PROTECTED بازنویسی شود.

http.proxySSLCAInfo

مسیر فایل حاوی بسته گواهی که باید هنگام استفاده از پروکسی HTTPS برای اعتبارسنجی پروکسی استفاده شود. می‌تواند توسط متغیر محیطی GIT_PROXY_SSL_CAINFO بازنویسی شود.

http.emptyAuth

تلاش برای احراز هویت بدون درخواست نام کاربری یا گذرواژه. این می‌تواند برای تلاش جهت احراز هویت GSS-Negotiate بدون تعیین نام کاربری در URL استفاده شود، زیرا libcurl معمولاً برای احراز هویت به نام کاربری نیاز دارد. مقادیر ممکن عبارتند از:
•auto (پیش‌فرض) - ارسال اطلاعات اعتبارنامه خالی تنها در صورتی که پاسخ 401 سرور سازوکار احراز هویتی را اعلام کند که به آنها نیاز دارد (مانند GSS-Negotiate)؛ در غیر این صورت به درخواست از طریق دستیار اعتبارنامه رجوع می‌کند.
•true - همیشه در همان اولین درخواست، پیش از دریافت هرگونه پاسخ 401 از سرور، اعتبارنامه‌های خالی ارسال شود.
•false - هرگز اعتبارنامه‌های خالی ارسال نشود. سازوکارهایی که به اعتبارنامه‌های خالی یا یک نام کاربری صریح نیاز دارند، مانند GSS-Negotiate، کار نخواهند کرد.

http.proactiveAuth

تلاش برای احراز هویت بدون انجام تلاش اولیه بدون احراز هویت و دریافت پاسخ 401. این می‌تواند برای اطمینان از احراز هویت تمام درخواست‌ها استفاده شود. اگر http.emptyAuth روی true تنظیم شده باشد، این مقدار تاثیری ندارد.

اگر دستیار اعتبارنامه مورد استفاده، یک طرح احراز هویت را مشخص کند (یعنی از طریق فیلد authtype)، آن مقدار استفاده خواهد شد؛ اگر نام کاربری و گذرواژه بدون طرح مشخصی ارائه شوند، احراز هویت Basic استفاده می‌شود. مقدار این گزینه، طرح درخواستی از دستیار را تعیین می‌کند. مقادیر ممکن عبارتند از:

•basic - درخواست احراز هویت Basic از دستیار.
•auto - اجازه دادن به دستیار برای انتخاب طرح مناسب.
•none - غیرفعال کردن احراز هویت پیش‌دستانه.

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

http.delegation

تفویض اعتبارنامه GSSAPI را کنترل می‌کند. تفویض به طور پیش‌فرض در libcurl از نسخه 7.21.7 غیرفعال است. این پارامتر را تنظیم کنید تا به سرور اعلام شود در مورد اعتبارنامه‌های کاربر مجاز به تفویض چه چیزی است. همراه با GSS/kerberos استفاده می‌شود. مقادیر ممکن عبارتند از:
•none - هیچ تفویضی مجاز نباشد.
•policy - تفویض تنها و تنها در صورتی انجام شود که پرچم OK-AS-DELEGATE در بلیت سرویس Kerberos تنظیم شده باشد، که به خط‌مشی قلمرو مربوط می‌شود.
•always - سرور بدون قید و شرط مجاز به تفویض باشد.

http.extraHeader

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

http.cookieFile

مسیر فایلی حاوی خطوط کوکی قبلاً ذخیره‌شده، که در صورت تطابق با سرور باید در نشست http گیت استفاده شوند. قالب فایل برای خواندن کوکی‌ها باید سرآیندهای ساده HTTP یا قالب فایل کوکی Netscape/Mozilla باشد (ببینید curl(1)). آن را روی یک رشته خالی تنظیم کنید تا فقط کوکی‌های جدید از سرور پذیرفته شوند و در درخواست‌های متوالی در همان اتصال بازگردانده شوند. توجه داشته باشید که فایل مشخص‌شده با http.cookieFile تنها به عنوان ورودی استفاده می‌شود مگر اینکه http.saveCookies تنظیم شده باشد.

http.saveCookies

در صورت تنظیم، کوکی‌های دریافت‌شده در طول درخواست‌ها را در فایل مشخص‌شده توسط http.cookieFile ذخیره می‌کند. اگر http.cookieFile تنظیم نشده باشد یا روی یک رشته خالی تنظیم شده باشد، هیچ اثری ندارد.

http.version

هنگام برقراری ارتباط با یک سرور از نسخه پروتکل مشخص‌شده HTTP استفاده می‌کند، در صورتی که بخواهید بر مقدار پیش‌فرض پافشاری کنید. نسخه موجود و پیش‌فرض به libcurl بستگی دارد. در حال حاضر مقادیر ممکن برای این گزینه عبارتند از:
•HTTP/2
•HTTP/1.1

http.curloptResolve

اطلاعات تفکیک نام میزبان که هنگام ارسال درخواست‌های HTTP ابتدا توسط libcurl استفاده خواهد شد. این اطلاعات باید در یکی از قالب‌های زیر باشد:
•[+]HOST:PORT:ADDRESS[,ADDRESS]
•-HOST:PORT

قالب اول تمام درخواست‌ها به HOST:PORT داده‌شده را به ADDRESS(های) ارائه‌شده هدایت می‌کند. قالب دوم تمام مقادیر پیکربندی قبلی را برای آن ترکیب HOST:PORT پاک می‌کند. برای امکان بازنویسی آسان تمام تنظیمات به ارث رسیده از پیکربندی سیستم، یک مقدار خالی تمام اطلاعات تفکیک را به فهرست خالی بازنشانی می‌کند.

http.sslVersion

نسخه SSL برای استفاده هنگام مذاکره بر سر اتصال SSL، در صورتی که بخواهید بر مقدار پیش‌فرض پافشاری کنید. نسخه موجود و پیش‌فرض به این بستگی دارد که آیا libcurl در برابر NSS ساخته شده است یا OpenSSL و همچنین به پیکربندی خاص کتابخانه رمزنوشتاری مورد استفاده وابسته است. به صورت داخلی این متغیر گزینه CURLOPT_SSL_VERSION را تنظیم می‌کند؛ برای جزئیات بیشتر در مورد قالب این گزینه و نسخه ssl پشتیبانی‌شده به مستندات libcurl مراجعه کنید. در حال حاضر مقادیر ممکن برای این گزینه عبارتند از:
•sslv2
•sslv3
•tlsv1
•tlsv1.0
•tlsv1.1
•tlsv1.2
•tlsv1.3

می‌تواند توسط متغیر محیطی GIT_SSL_VERSION بازنویسی شود. برای اجبار git به استفاده از نسخه پیش‌فرض ssl در libcurl و نادیده گرفتن هر گزینه صریح http.sslversion، متغیر GIT_SSL_VERSION را روی یک رشته خالی تنظیم کنید.

http.sslCipherList

فهرستی از الگوریتم‌های رمزنگاری (ciphers) SSL برای استفاده هنگام مذاکره بر سر یک اتصال SSL. الگوریتم‌های رمزنگاری در دسترس به این بستگی دارند که libcurl در برابر NSS ساخته شده است یا OpenSSL و همچنین به پیکربندی خاص کتابخانه رمزنوشتاری مورد استفاده وابسته است. به صورت داخلی این متغیر گزینه CURLOPT_SSL_CIPHER_LIST را تنظیم می‌کند؛ برای جزئیات بیشتر درباره قالب این فهرست به مستندات libcurl مراجعه کنید.

می‌تواند توسط متغیر محیطی GIT_SSL_CIPHER_LIST بازنویسی شود. برای اجبار git به استفاده از فهرست پیش‌فرض الگوریتم‌های رمزنگاری libcurl و نادیده گرفتن هر گزینه صریح http.sslCipherList، متغیر GIT_SSL_CIPHER_LIST را روی یک رشته خالی تنظیم کنید.

http.sslVerify

آیا گواهی SSL هنگام واکشی یا ارسال روی HTTPS اعتبارسنجی شود یا خیر. پیش‌فرض true است. می‌تواند توسط متغیر محیطی GIT_SSL_NO_VERIFY بازنویسی شود.

http.sslCert

فایل حاوی گواهی SSL هنگام واکشی یا ارسال روی HTTPS. می‌تواند توسط متغیر محیطی GIT_SSL_CERT بازنویسی شود.

http.sslKey

فایل حاوی کلید خصوصی SSL هنگام واکشی یا ارسال روی HTTPS. می‌تواند توسط متغیر محیطی GIT_SSL_KEY بازنویسی شود.

http.sslCertPasswordProtected

درخواست دریافت گذرواژه Git برای گواهی SSL را فعال می‌کند. در غیر این صورت، اگر گواهی یا کلید خصوصی رمزنگاری شده باشد، OpenSSL ممکن است مکرراً از کاربر درخواست گذرواژه کند. می‌تواند توسط متغیر محیطی GIT_PROXY_SSL_CERT_PASSWORD_PROTECTED بازنویسی شود.

http.sslCAInfo

فایل حاوی گواهی‌ها برای اعتبارسنجی طرف مقابل (peer) هنگام واکشی یا ارسال روی HTTPS. می‌تواند توسط متغیر محیطی GIT_SSL_CAINFO بازنویسی شود.

http.sslCAPath

مسیر حاوی فایل‌های گواهی‌های CA برای اعتبارسنجی طرف مقابل هنگام واکشی یا ارسال روی HTTPS. می‌تواند توسط متغیر محیطی GIT_SSL_CAPATH بازنویسی شود.

http.sslBackend

نام بک‌اند SSL برای استفاده (مثلاً "openssl" یا "schannel"). اگر cURL فاقد پشتیبانی برای انتخاب بک‌اند SSL در زمان اجرا باشد، این گزینه نادیده گرفته می‌شود.

http.sslCertType

نوع گواهی کلاینت مورد استفاده هنگام واکشی یا ارسال روی HTTPS. مقادیر "PEM" و "DER" هنگام استفاده از بک‌اندهای openssl یا gnutls پشتیبانی می‌شوند. مقدار "P12" روی "openssl"، "schannel"، "securetransport" و gnutls نسخه 8.11+ پشتیبانی می‌شود. همچنین رجوع کنید به CURLOPT_SSLCERTTYPE در libcurl. می‌تواند توسط متغیر محیطی GIT_SSL_CERT_TYPE بازنویسی شود.

http.sslKeyType

نوع کلید خصوصی کلاینت مورد استفاده هنگام واکشی یا ارسال روی HTTPS (مثلاً "PEM"، "DER" یا "ENG"). تنها هنگام استفاده از بک‌اند "openssl" قابل اعمال است. مقدار "DER" با openssl پشتیبانی نمی‌شود. به ویژه هنگام تنظیم روی "ENG" برای احراز هویت با توکن‌های PKCS#11 به همراه یک URL مربوط به PKCS#11 در گزینه sslCert بسیار مفید است. همچنین رجوع کنید به CURLOPT_SSLKEYTYPE در libcurl. می‌تواند توسط متغیر محیطی GIT_SSL_KEY_TYPE بازنویسی شود.

http.schannelCheckRevoke

برای اجبار یا غیرفعال کردن بررسی ابطال گواهی در cURL هنگامی که http.sslBackend روی "schannel" تنظیم شده است، استفاده می‌شود. در صورت عدم تنظیم، پیش‌فرض true است. غیرفعال کردن این گزینه تنها در صورتی ضروری است که Git مداوماً با خطا مواجه شود و پیام خطا مربوط به بررسی وضعیت ابطال یک گواهی باشد. اگر cURL فاقد پشتیبانی برای تنظیم گزینه مربوطه SSL در زمان اجرا باشد، این گزینه نادیده گرفته می‌شود.

http.schannelUseSSLCAInfo

از نسخه cURL v7.60.0 به بعد، بک‌اند Secure Channel می‌تواند از بسته گواهی ارائه‌شده از طریق http.sslCAInfo استفاده کند، اما این کار انبار گواهی ویندوز (Windows Certificate Store) را بازنویسی می‌کند. از آنجا که این رفتار به طور پیش‌فرض مطلوب نیست، Git به cURL می‌گوید هنگامی که بک‌اند schannel از طریق http.sslBackend پیکربندی شده است، به طور پیش‌فرض از آن بسته استفاده نکند، مگر اینکه http.schannelUseSSLCAInfo این رفتار را بازنویسی کند.

http.pinnedPubkey

کلید عمومی سرویس https. این می‌تواند نام فایل یک فایل کلید عمومی با کدگذاری PEM یا DER باشد، یا رشته‌ای که با sha256// آغاز شده و پس از آن هش sha256 کدگذاری‌شده با base64 از کلید عمومی قرار دارد. همچنین رجوع کنید به CURLOPT_PINNEDPUBLICKEY در libcurl. اگر این گزینه تنظیم شود اما توسط cURL پشتیبانی نشود، git با یک خطا خارج خواهد شد.

http.sslTry

تلاش برای استفاده از AUTH SSL/TLS و انتقال داده‌های رمزشده هنگام اتصال از طریق پروتکل معمولی FTP. این ممکن است در صورتی لازم باشد که سرور FTP به دلایل امنیتی به آن نیاز داشته باشد یا شما بخواهید هر زمان که سرور FTP ریموت از آن پشتیبانی می‌کند به صورت امن متصل شوید. مقدار پیش‌فرض false است زیرا ممکن است در سرورهایی با پیکربندی نادرست خطاهای اعتبارسنجی گواهی ایجاد کند.

http.maxRequests

چه تعداد درخواست HTTP به صورت موازی اجرا شوند. می‌تواند توسط متغیر محیطی GIT_HTTP_MAX_REQUESTS بازنویسی شود. پیش‌فرض 5 است.

http.minSessions

تعداد نشست‌های curl (شمارش‌شده در اسلات‌ها) که باید در طول درخواست‌ها باز نگه داشته شوند. آن‌ها تا زمان فراخوانی http_cleanup() با curl_easy_cleanup() پایان نخواهند یافت. اگر USE_CURL_MULTI تعریف نشده باشد، این مقدار حداکثر به ۱ محدود می‌شود. پیش‌فرض ۱ است.

http.postBuffer

حداکثر اندازه بر حسب بایت برای بافر مورد استفاده توسط انتقالات هوشمند HTTP هنگام ارسال داده به سیستم ریموت با POST. برای درخواست‌های بزرگتر از این اندازه بافر، از HTTP/1.1 و Transfer-Encoding: chunked استفاده می‌شود تا از ایجاد یک فایل بسته بسیار بزرگ به صورت محلی جلوگیری شود. مقدار پیش‌فرض 1 MiB است که برای اکثر درخواست‌ها کافی می‌باشد.

توجه داشته باشید که افزایش این حد تنها برای غیرفعال کردن کدگذاری انتقال تکه‌ای موثر است و بنابراین فقط باید در جایی استفاده شود که سرور ریموت یا پروکسی تنها از HTTP/1.0 پشتیبانی می‌کند یا با استاندارد HTTP سازگار نیست. افزایش این مقدار به طور کلی راه‌حل موثری برای اکثر مشکلات push نیست، اما می‌تواند مصرف حافظه را به شدت افزایش دهد زیرا کل بافر حتی برای ارسال‌های کوچک نیز تخصیص داده می‌شود.

http.lowSpeedLimit, http.lowSpeedTime

اگر سرعت انتقال HTTP بر حسب بایت در ثانیه، کمتر از http.lowSpeedLimit برای مدت زمانی بیش از http.lowSpeedTime ثانیه باشد، انتقال متوقف می‌شود. می‌تواند توسط متغیرهای محیطی GIT_HTTP_LOW_SPEED_LIMIT و GIT_HTTP_LOW_SPEED_TIME بازنویسی شود.

http.keepAliveIdle

مدت زمان انتظار بر حسب ثانیه را روی یک اتصال بیکار پیش از ارسال کاوشگرهای TCP keepalive (در صورت پشتیبانی سیستم‌عامل) مشخص می‌کند. اگر تنظیم نشده باشد، مقدار پیش‌فرض curl استفاده می‌شود. می‌تواند توسط متغیر محیطی GIT_HTTP_KEEPALIVE_IDLE بازنویسی شود.

http.keepAliveInterval

مدت زمان انتظار بر حسب ثانیه میان کاوشگرهای TCP keepalive را (در صورت پشتیبانی سیستم‌عامل) مشخص می‌کند. اگر تنظیم نشده باشد، مقدار پیش‌فرض curl استفاده می‌شود. می‌تواند توسط متغیر محیطی GIT_HTTP_KEEPALIVE_INTERVAL بازنویسی شود.

http.keepAliveCount

مشخص می‌کند چه تعداد کاوشگر TCP keepalive پیش از صرف‌نظر کردن و قطع اتصال (در صورت پشتیبانی سیستم‌عامل) ارسال شود. اگر تنظیم نشده باشد، مقدار پیش‌فرض curl استفاده می‌شود. می‌تواند توسط متغیر محیطی GIT_HTTP_KEEPALIVE_COUNT بازنویسی شود.

http.retryAfter

زمان انتظار پیش‌فرض بر حسب ثانیه قبل از تلاش مجدد، زمانی که سرور پاسخ HTTP 429 (Too Many Requests) را بدون سرآیند Retry-After برمی‌گرداند. پیش‌فرض 0 (تلاش مجدد فوری) است. هنگامی که سرآیند Retry-After وجود داشته باشد، مقدار آن بر این تنظیم اولویت دارد؛ با این حال، استفاده خودکار از سرآیند Retry-After ارائه‌شده توسط سرور نیازمند libcurl نسخه 7.66.0 یا جدیدتر است. در نسخه‌های قدیمی‌تر، این تنظیم را به صورت دستی پیکربندی کنید تا تاخیر تلاش مجدد را کنترل نمایید. می‌تواند توسط متغیر محیطی GIT_HTTP_RETRY_AFTER بازنویسی شود. همچنین ببینید http.maxRetries و http.maxRetryTime.

http.maxRetries

حداکثر تعداد دفعات تلاش مجدد پس از دریافت پاسخ‌های HTTP 429 (Too Many Requests). برای غیرفعال کردن تلاش‌های مجدد، آن را روی 0 (پیش‌فرض) قرار دهید. می‌تواند توسط متغیر محیطی GIT_HTTP_MAX_RETRIES بازنویسی شود. همچنین ببینید http.retryAfter و http.maxRetryTime.

http.maxRetryTime

حداکثر زمان بر حسب ثانیه برای انتظار جهت یک تلاش مجدد منفرد هنگام رسیدگی به پاسخ‌های HTTP 429 (Too Many Requests). اگر سرور درخواست تاخیر کند (از طریق سرآیند Retry-After) یا اگر http.retryAfter با مقداری پیکربندی شده باشد که از این حداکثر فراتر رود، Git به جای انتظار بلافاصله با خطا متوقف می‌شود. پیش‌فرض 300 ثانیه (5 دقیقه) است. می‌تواند توسط متغیر محیطی GIT_HTTP_MAX_RETRY_TIME بازنویسی شود. همچنین ببینید http.retryAfter و http.maxRetries.

http.noEPSV

یک مقدار بولی که استفاده از دستور ftp موسوم به EPSV توسط curl را غیرفعال می‌کند. این می‌تواند در مواجهه با برخی سرورهای ftp ضعیف که از حالت EPSV پشتیبانی نمی‌کنند مفید باشد. می‌تواند توسط متغیر محیطی GIT_CURL_FTP_NO_EPSV بازنویسی شود. پیش‌فرض false است (curl از EPSV استفاده خواهد کرد).

http.userAgent

رشته USER_AGENT پروتکل HTTP ارائه‌شده به یک سرور HTTP. مقدار پیش‌فرض بیانگر نسخه کلاینت Git است، مانند git/1.7.1. این گزینه به شما امکان می‌دهد این مقدار را با مقداری متداول‌تر مانند Mozilla/4.0 بازنویسی کنید. برای نمونه، در صورتی که اتصال از طریق یک فایروال انجام شود که اتصالات HTTP را به مجموعه‌ای از رشته‌های متداول USER_AGENT محدود می‌کند (و مواردی مانند git/1.7.1 را در بر نمی‌گیرد)، ممکن است لازم باشد. می‌تواند توسط متغیر محیطی GIT_HTTP_USER_AGENT بازنویسی شود.

http.followRedirects

آیا git باید تغییر مسیرهای HTTP را دنبال کند یا خیر. اگر روی true تنظیم شود، git به صورت شفاف هرگونه تغییر مسیری که توسط سرور صادر شود را دنبال خواهد کرد. اگر روی false تنظیم شود، git با تمام تغییر مسیرها به عنوان خطا برخورد می‌کند. اگر روی initial تنظیم شود، git تغییر مسیرها را تنها برای درخواست اولیه به یک ریموت دنبال می‌کند، اما نه برای درخواست‌های متوالی بعدی HTTP. از آنجا که git از URL تغییر مسیر یافته به عنوان مبنا برای درخواست‌های بعدی استفاده می‌کند، این حالت عموماً کافی است. مقدار پیش‌فرض initial است.

http.<url>.*

هر یک از گزینه‌های http.* بالا را می‌توان به صورت انتخابی روی برخی URLها اعمال کرد. برای اینکه یک کلید پیکربندی با یک URL مطابقت داشته باشد، هر عنصر از کلید پیکربندی با عنصر متناظر در URL، به ترتیب زیر مقایسه می‌شود:
1.طرح (مثلاً https در https://example.com/). این فیلد باید بین کلید پیکربندی و URL دقیقاً مطابقت داشته باشد.
2.نام میزبان/دامنه (مثلاً example.com در https://example.com/). این فیلد باید بین کلید پیکربندی و URL مطابقت داشته باشد. امکان تعیین یک * به عنوان بخشی از نام میزبان برای تطبیق با تمام زیردامنه‌ها در این سطح وجود دارد. برای مثال https://*.example.com/ با https://foo.example.com/ مطابقت دارد، اما با https://foo.bar.example.com/ تطابق ندارد.
3.شماره پورت (مثلاً 8080 در http://example.com:8080/). این فیلد باید بین کلید پیکربندی و URL دقیقاً مطابقت داشته باشد. شماره پورت‌های حذف‌شده قبل از تطبیق به طور خودکار به مقدار پیش‌فرض صحیح برای طرح مربوطه تبدیل می‌شوند.
4.مسیر (مثلاً repo.git در https://example.com/repo.git). فیلد مسیر کلید پیکربندی باید با فیلد مسیر URL به صورت دقیق یا به عنوان پیشوندی از عناصر مسیر تفکیک‌شده با اسلش مطابقت داشته باشد. این بدان معناست که یک کلید پیکربندی با مسیر foo/ با مسیر URL foo/bar تطابق دارد. یک پیشوند تنها می‌تواند روی مرز اسلش (/) مطابقت یابد. تطابق‌های طولانی‌تر اولویت دارند (بنابراین یک کلید پیکربندی با مسیر foo/bar نسبت به کلید پیکربندی با صرف مسیر foo/ تطابق بهتری با مسیر URL foo/bar دارد).
5.نام کاربری (مثلاً user در https://user@example.com/repo.git). اگر کلید پیکربندی دارای نام کاربری باشد، باید دقیقاً با نام کاربری موجود در URL مطابقت داشته باشد. اگر کلید پیکربندی نام کاربری نداشته باشد، آن کلید با هر نام کاربری در URL (از جمله بدون نام کاربری) مطابقت خواهد داشت، اما با اولویتی کمتر نسبت به کلید دارای نام کاربری.

فهرست فوق به ترتیب اولویت نزولی مرتب شده است؛ یک URL که با مسیر یک کلید پیکربندی مطابقت دارد، نسبت به موردی که با نام کاربری آن مطابقت دارد ترجیح داده می‌شود. برای مثال، اگر URL برابر با https://user@example.com/foo/bar باشد، تطابق کلید پیکربندی با https://example.com/foo بر تطابق کلید پیکربندی با https://user@example.com ترجیح داده خواهد شد.

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

i18n.commitEncoding

کدگذاری نویسه‌ها که پیام‌های ثبت در آن ذخیره می‌شوند؛ خود Git به خودی خود اهمیتی به آن نمی‌دهد، اما این اطلاعات مثلاً هنگام وارد کردن کامیت‌ها از ایمیل‌ها یا در مرورگر گرافیکی تاریخچه gitk (و احتمالاً در مکان‌های دیگر در آینده یا در سایر رابط‌های سطح بالا) ضروری است. به عنوان مثال رجوع کنید به git-mailinfo(1). مقدار پیش‌فرض utf-8 است.

i18n.logOutputEncoding

کدگذاری نویسه‌ها که هنگام اجرای git log و دستورات مرتبط، پیام‌های ثبت به آن تبدیل می‌شوند.

imap.folder

پوشه‌ای که نامه‌ها باید در آن قرار گیرند، که معمولاً پوشه پیش‌نویس‌ها (Drafts) است. برای مثال: INBOX.Drafts, INBOX/Drafts یا [Gmail]/Drafts. پوشه IMAP برای تعامل حتماً باید مشخص شود؛ مقدار این متغیر پیکربندی به عنوان مقدار پیش‌فرض جایگزین در صورتی که گزینه --folder داده نشده باشد، استفاده می‌شود.

imap.tunnel

دستوری که برای ایجاد یک تونل به سرور IMAP استفاده می‌شود تا دستورات به جای استفاده از اتصال مستقیم شبکه‌ای به سرور، از طریق آن هدایت شوند. در صورتی که imap.host تنظیم نشده باشد، الزامی است.

imap.host

یک URL که سرور را مشخص می‌کند. از یک پیشوند imap:// برای اتصالات غیرامن و یک پیشوند imaps:// برای اتصالات امن استفاده کنید. هنگامی که imap.tunnel تنظیم شده باشد نادیده گرفته می‌شود، اما در غیر این صورت الزامی است.

imap.user

نام کاربری مورد استفاده هنگام ورود به سرور.

imap.pass

گذرواژه مورد استفاده هنگام ورود به سرور.

imap.port

یک عدد صحیح برای پورت اتصال به سرور. پیش‌فرض 143 برای میزبان‌های imap:// و 993 برای میزبان‌های imaps:// است. هنگامی که imap.tunnel تنظیم شده باشد نادیده گرفته می‌شود.

imap.sslverify

یک مقدار بولی برای فعال/غیرفعال کردن اعتبارسنجی گواهی سرور مورد استفاده توسط اتصال SSL/TLS. پیش‌فرض true است. هنگامی که imap.tunnel تنظیم شده باشد نادیده گرفته می‌شود.

imap.preformattedHTML

یک مقدار بولی برای فعال/غیرفعال کردن استفاده از کدگذاری html هنگام ارسال وصله. یک وصله کدگذاری‌شده با html درون تگ‌های <pre> قرار می‌گیرد و نوع محتوای text/html خواهد داشت. جالب اینجاست که فعال کردن این گزینه باعث می‌شود Thunderbird وصله را به صورت یک ایمیل plain/text با format=fixed ارسال کند. مقدار پیش‌فرض false است.

imap.authMethod

روش احراز هویت را برای احراز هویت در سرور IMAP مشخص می‌کند. اگر Git با گزینه NO_CURL ساخته شده باشد، یا اگر نسخه curl شما قدیمی‌تر از 7.34.0 باشد، یا اگر git-imap-send را با گزینه --no-curl اجرا می‌کنید، تنها روش‌های پشتیبانی‌شده عبارتند از PLAIN, CRAM-MD5, OAUTHBEARER و XOAUTH2. اگر این مقدار تنظیم نشده باشد، git imap-send از دستور متنی ساده IMAP یعنی LOGIN استفاده می‌کند.

include.path, includeIf.<condition>.path

متغیرهای ویژه برای گنجاندن سایر فایل‌های پیکربندی. به بخش "CONFIGURATION FILE" در مستندات اصلی git-config(1)، به ویژه زیربخش‌های "Includes" و "Conditional Includes" مراجعه کنید.

index.recordEndOfIndexEntries

مشخص می‌کند که آیا فایل ایندکس باید شامل بخش "End Of Index Entry" باشد یا خیر. این کار زمان بارگذاری ایندکس را در ماشین‌های چندپردازنده‌ای کاهش می‌دهد، اما هنگام خواندن ایندکس با استفاده از نسخه‌های Git پیش از 2.20 پیام "ignoring EOIE extension" تولید می‌کند. در صورتی که index.threads به طور صریح فعال شده باشد پیش‌فرض true است، در غیر این صورت false می‌باشد.

index.recordOffsetTable

مشخص می‌کند که آیا فایل ایندکس باید شامل بخش "Index Entry Offset Table" باشد یا خیر. این کار زمان بارگذاری ایندکس را در ماشین‌های چندپردازنده‌ای کاهش می‌دهد، اما هنگام خواندن ایندکس با استفاده از نسخه‌های Git پیش از 2.20 پیام "ignoring IEOT extension" تولید می‌کند. در صورتی که index.threads به طور صریح فعال شده باشد پیش‌فرض true است، در غیر این صورت false می‌باشد.

index.sparse

در صورت فعال بودن، ایندکس را با استفاده از مدخل‌های دایرکتوری خلوت (sparse-directory) می‌نویسد. این گزینه تاثیری ندارد مگر اینکه هر دو core.sparseCheckout و core.sparseCheckoutCone فعال باشند. پیش‌فرض false است.

index.threads

تعداد نخ‌هایی را مشخص می‌کند که باید هنگام بارگذاری ایندکس ایجاد شوند. هدف از این کار کاهش زمان بارگذاری ایندکس روی ماشین‌های چندپردازنده‌ای است. تعیین 0 یا true باعث می‌شود Git تعداد CPUها را به طور خودکار شناسایی کرده و تعداد نخ‌ها را متناسب با آن تنظیم کند. تعیین 1 یا false چندنخی را غیرفعال می‌کند. پیش‌فرض true است.

index.version

نسخه‌ای را مشخص می‌کند که فایل‌های ایندکس جدید باید با آن مقداردهی اولیه شوند. این گزینه بر مخازن موجود تاثیری ندارد. اگر feature.manyFiles فعال باشد، مقدار پیش‌فرض 4 است.

index.skipHash

در صورت فعال بودن، هش پایانی فایل ایندکس محاسبه نمی‌شود. این کار به اجرای سریع‌تر دستورات Git که ایندکس را دستکاری می‌کنند، مانند git add, git commit, یا git status کمک می‌کند. به جای ذخیره مجموع مقابله‌ای (checksum)، مجموعه‌ای از بایت‌های پایانی با مقدار صفر نوشته می‌شود که نشان می‌دهد از محاسبه صرف‌نظر شده است.

اگر index.skipHash را فعال کنید، کلاینت‌های Git قدیمی‌تر از 2.13.0 از تجزیه ایندکس خودداری می‌کنند و کلاینت‌های Git قدیمی‌تر از 2.40.0 در حین اجرای git fsck خطا گزارش می‌دهند.

init.templateDir

دایرکتوری را مشخص می‌کند که الگوها از آن کپی خواهند شد. (به بخش "TEMPLATE DIRECTORY" در git-init(1) مراجعه کنید.)

init.defaultBranch

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

init.defaultObjectFormat

امکان بازنویسی قالب پیش‌فرض شیء را برای مخازن جدید فراهم می‌کند. ببینید --object-format= در git-init(1). هم گزینه خط فرمان و هم متغیر محیطی GIT_DEFAULT_HASH بر این پیکربندی اولویت دارند.

init.defaultRefFormat

امکان بازنویسی قالب پیش‌فرض ذخیره‌سازی مراجع را برای مخازن جدید فراهم می‌کند. ببینید --ref-format= در git-init(1). هم گزینه خط فرمان و هم متغیر محیطی GIT_DEFAULT_REF_FORMAT بر این پیکربندی اولویت دارند.

init.defaultSubmodulePathConfig

یک مقدار بولی که مشخص می‌کند آیا git init و git clone باید به طور خودکار extensions.submodulePathConfig را روی true تنظیم کنند یا خیر. این به تمام مخازن جدید اجازه می‌دهد تا به صورت خودکار از افزونه مسیر زیرماژول استفاده کنند. در صورت عدم تنظیم، پیش‌فرض false است.

instaweb.browser

برنامه‌ای را مشخص می‌کند که برای مرور مخزن کاری شما در gitweb استفاده خواهد شد. ببینید git-instaweb(1).

instaweb.httpd

خط فرمان دیمن HTTP برای راه‌اندازی gitweb روی مخزن کاری شما. ببینید git-instaweb(1).

instaweb.local

اگر روی true تنظیم باشد، وب‌سرور راه‌اندازی‌شده توسط git-instaweb(1) به IP محلی (127.0.0.1) متصل خواهد شد.

instaweb.modulePath

مسیر پیش‌فرض ماژول برای استفاده توسط git-instaweb(1) به جای /usr/lib/apache2/modules. تنها در صورتی استفاده می‌شود که httpd آپاچی باشد.

instaweb.port

شماره پورتی که httpd مربوط به gitweb باید به آن متصل شود. ببینید git-instaweb(1).

interactive.singleKey

هنگامی که روی true تنظیم شود، به کاربر اجازه می‌دهد در دستورات تعاملی ورودی یک‌حرفی را با فشردن یک کلید (یعنی بدون فشردن کلید Enter) ارائه دهد. این در حال حاضر توسط حالت --patch در دستورات git-add(1), git-checkout(1), git-restore(1), git-commit(1), git-reset(1) و git-stash(1) استفاده می‌شود.

interactive.diffFilter

هنگامی که یک دستور تعاملی (مانند git add --patch) یک diff رنگی را نشان می‌دهد، git تفاضل (diff) را از طریق دستور شل تعریف‌شده توسط این متغیر پیکربندی هدایت (pipe) می‌کند. این دستور می‌تواند diff را برای درک بهتر توسط انسان بیشتر نشانه‌گذاری کند، به شرط آنکه تطابق یک‌به‌یک با خطوط diff اصلی حفظ شود. پیش‌فرض غیرفعال است (بدون فیلتر کردن).

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" تنظیم شده باشد و صفحه‌بند در حال استفاده باشد، از قالب "foo" برای تاریخ استفاده خواهد شد. در غیر این صورت از "default" استفاده می‌شود.

log.decorate

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

short

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

full

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

auto

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

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

log.initialDecorationSet

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

log.excludeDecoration

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

log.diffMerges

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

log.follow

اگر true باشد، زمانی که یک <path> واحد داده می‌شود، git log به گونه‌ای عمل می‌کند که گویی گزینه --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 است.

lsrefs.unborn

می‌تواند "advertise" (پیش‌فرض)، "allow" یا "ignore" باشد. اگر "advertise" باشد، کارساز (سرور) به کلاینتی که "unborn" ارسال می‌کند پاسخ خواهد داد (همان‌طور که در gitprotocol-v2(5) توصیف شده است) و پشتیبانی از این ویژگی را در طول اعلان قابلیت‌های پروتکل نسخه ۲ تبلیغ (اعلام) خواهد کرد. مقدار "allow" همانند "advertise" است با این تفاوت که سرور پشتیبانی از این ویژگی را اعلام نخواهد کرد؛ این قابلیت برای سرورهای با بار متوازن (load-balanced) که نمی‌توانند به‌صورت هم‌زمان و یکپارچه به‌روزرسانی شوند مفید است (برای مثال)، زیرا مدیر سیستم می‌تواند ابتدا "allow" را پیکربندی کرده و سپس پس از مدتی تأخیر، "advertise" را تنظیم نماید.

mailinfo.scissors

اگر true باشد، باعث می‌شود git-mailinfo(1) (و در نتیجه git-am(1)) به‌طور پیش‌فرض به گونه‌ای عمل کنند که گویی گزینه --scissors در خط فرمان ارائه شده است. هنگامی که فعال باشد، این ویژگی همه چیز را از بدنه پیام قبل از خط قیچی (scissors line، یعنی خطی عمدتاً شامل ">8"، "8<" و "-") حذف می‌کند.

mailmap.file

مکان یک فایل mailmap تکمیلی. فایل mailmap پیش‌فرض واقع در ریشه مخزن، ابتدا بارگذاری می‌شود و سپس فایل mailmap که توسط این متغیر مشخص شده است. مکان فایل mailmap می‌تواند در یک زیرپوشه از مخزن یا در جایی بیرون از خود مخزن باشد. ببینید: git-shortlog(1) و git-blame(1).

mailmap.blob

مشابه mailmap.file، اما مقدار را به عنوان مرجعی به یک blob در مخزن در نظر می‌گیرد. اگر هر دو mailmap.file و mailmap.blob مشخص شوند، هر دو تجزیه می‌شوند و مدخل‌های mailmap.file اولویت خواهند داشت. در یک مخزن bare، مقدار پیش‌فرض آن HEAD:.mailmap است. در مخزن غیر bare، مقدار پیش‌فرض خالی است.

maintenance.auto

این گزینه پیکربندی بولی کنترل می‌کند که آیا برخی دستورات پس از انجام کار عادی خود، git maintenance run --auto را اجرا کنند یا خیر. پیش‌فرض روی true است.

maintenance.autoDetach

بسیاری از دستورات Git پس از نوشتن داده‌ها در مخزن، نگهداری خودکار را راه‌اندازی می‌کنند. این گزینه پیکربندی بولی کنترل می‌کند که آیا این نگهداری خودکار باید در پیش‌زمینه انجام شود یا اینکه فرآیند نگهداری باید جدا شده (detach) و در پس‌زمینه به اجرا ادامه دهد.

در صورت تنظیم نشدن، مقدار gc.autoDetach به عنوان جایگزین استفاده می‌شود. اگر هر دو تنظیم نشده باشند، پیش‌فرض true است، به این معنی که فرآیند نگهداری جدا خواهد شد.

maintenance.strategy

این گزینه پیکربندی رشته‌ای راهکاری برای تعیین یکی از راهبردهای توصیه‌شده برای نگهداری مخزن فراهم می‌کند. این تنظیم تعیین می‌کند که در حین اجرای git maintenance run چه وظایفی اجرا شوند، به شرطی که هیچ آرگومان --task=<task> ارائه نشده باشد. این تنظیم بر نگهداری دستی، نگهداری خودکار و همچنین نگهداری زمان‌بندی‌شده تأثیر می‌گذارد. وظایفی که اجرا می‌شوند ممکن است بسته به نوع نگهداری متفاوت باشند.

راهبرد نگهداری را می‌توان با تنظیم maintenance.<task>.enabled و maintenance.<task>.schedule بیشتر سفارشی کرد. در صورت تنظیم، این مقادیر به جای مقادیر پیش‌فرض ارائه‌شده توسط maintenance.strategy استفاده می‌شوند.

راهبردهای ممکن عبارتند از:

•none: این راهبرد به این معنی است که هیچ وظیفه‌ای اصلاً اجرا نمی‌شود. این راهبرد پیش‌فرض برای نگهداری زمان‌بندی‌شده است.
•gc: این راهبرد وظیفه gc را اجرا می‌کند.
•geometric: این راهبرد بسته‌بندی مجدد هندسی (geometric repacking) فایل‌های بسته را انجام داده و ساختارهای داده کمکی را به‌روز نگه می‌دارد. این راهبرد داده‌ها را در reflog منقضی می‌کند و درخت‌های کاری (worktrees) را که دیگر قابل مکان‌یابی نیستند حذف می‌نماید. هنگامی که راهبرد بسته‌بندی مجدد هندسی تصمیم بگیرد یک بسته‌بندی همه در یک (all-into-one) انجام دهد، برای تمام اشیاء غیرقابل‌دسترس یک cruft pack ایجاد می‌کند. اشیایی که از قبل بخشی از یک cruft pack هستند منقضی خواهند شد.

این راهبرد بسته‌بندی مجدد، جایگزینی کامل برای راهبرد gc بوده و برای مخازن بزرگ توصیه می‌شود. این راهبرد پیش‌فرض برای نگهداری دستی است. * incremental: این تنظیم برای انجام فعالیت‌های نگهداری کوچک که هیچ داده‌ای را حذف نمی‌کنند بهینه‌سازی شده است. این گزینه وظیفه gc را زمان‌بندی نمی‌کند، بلکه وظایف prefetch و commit-graph را به‌صورت ساعتی، وظایف loose-objects و incremental-repack را به‌صورت روزانه، و وظیفه pack-refs را به‌صورت هفتگی اجرا می‌کند. نگهداری دستی مخزن از وظیفه gc استفاده می‌کند.

maintenance.<task>.enabled

این گزینه پیکربندی بولی کنترل می‌کند که آیا وظیفه نگهداری با نام <task> زمانی که هیچ گزینه --task به git maintenance run مشخص نشده باشد اجرا شود یا خیر. در صورت وجود گزینه --task، این مقادیر پیکربندی نادیده گرفته می‌شوند. به‌طور پیش‌فرض، فقط maintenance.gc.enabled برابر با true است.

maintenance.<task>.schedule

این گزینه پیکربندی کنترل می‌کند که آیا <task> داده‌شده در طول یک دستور git maintenance run --schedule=<frequency> اجرا شود یا خیر. مقدار باید یکی از "hourly"، "daily" یا "weekly" باشد.

maintenance.commit-graph.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه commit-graph هر چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه commit-graph با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند که هر بار اجرا شود. در غیر این صورت، یک مقدار مثبت به این معنی است که دستور باید زمانی اجرا شود که تعداد کامیت‌های قابل‌دسترس که در فایل commit-graph نیستند حداقل به اندازه مقدار maintenance.commit-graph.auto باشد. مقدار پیش‌فرض ۱۰۰ است.

maintenance.loose-objects.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه loose-objects هر چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه loose-objects با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند که هر بار اجرا شود. در غیر این صورت، یک مقدار مثبت به این معنی است که دستور باید زمانی اجرا شود که تعداد اشیاء مستقل (loose objects) حداقل به اندازه مقدار maintenance.loose-objects.auto باشد. مقدار پیش‌فرض ۱۰۰ است.

maintenance.loose-objects.batchSize

این گزینه پیکربندی عدد صحیح حداکثر تعداد اشیاء مستقل نوشته‌شده در یک فایل بسته در طول وظیفه loose-objects را کنترل می‌کند. پیش‌فرض پنجاه هزار است. از مقدار 0 برای نشان دادن عدم وجود محدودیت استفاده کنید.

maintenance.incremental-repack.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه incremental-repack هر چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه incremental-repack با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند که هر بار اجرا شود. در غیر این صورت، یک مقدار مثبت به این معنی است که دستور باید زمانی اجرا شود که تعداد فایل‌های بسته خارج از multi-pack-index حداقل به اندازه مقدار maintenance.incremental-repack.auto باشد. مقدار پیش‌فرض ۱۰ است.

maintenance.geometric-repack.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه geometric-repack هر چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه geometric-repack با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند که هر بار اجرا شود. در غیر این صورت، یک مقدار مثبت به این معنی است که دستور باید یا زمانی اجرا شود که فایل‌های بسته‌ای وجود داشته باشند که برای حفظ تصاعد هندسی نیاز به ادغام با یکدیگر دارند، یا زمانی که حداقل این تعداد شیء مستقل وجود داشته باشد که در یک فایل بسته جدید نوشته شوند. مقدار پیش‌فرض ۱۰۰ است.

maintenance.geometric-repack.splitFactor

این گزینه پیکربندی عدد صحیح ضریب مورد استفاده برای دنباله هندسی را کنترل می‌کند. برای جزئیات بیشتر گزینه --geometric= را در git-repack(1) ببینید. پیش‌فرض 2 است.

maintenance.reflog-expire.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه reflog-expire هر چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه reflog-expire با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند که هر بار اجرا شود. در غیر این صورت، یک مقدار مثبت به این معنی است که دستور باید زمانی اجرا شود که تعداد مدخل‌های منقضی‌شده reflog در وقایع‌نگار مرجع "HEAD" حداقل به اندازه مقدار maintenance.loose-objects.auto باشد. مقدار پیش‌فرض ۱۰۰ است.

maintenance.rerere-gc.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه rerere-gc هر چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه rerere-gc با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند که هر بار اجرا شود. در غیر این صورت، هر مقدار مثبت به این معنی است که دستور زمانی اجرا خواهد شد که پوشه "rr-cache" وجود داشته باشد و حداقل یک مدخل داشته باشد، صرف‌نظر از اینکه بیات (stale) است یا خیر. این روش تجربی (heuristic) ممکن است در آینده بهبود یابد. مقدار پیش‌فرض ۱ است.

maintenance.worktree-prune.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه worktree-prune هر چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه worktree-prune با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند که هر بار اجرا شود. در غیر این صورت، یک مقدار مثبت به این معنی است که دستور باید زمانی اجرا شود که تعداد درخت‌های کاری قابل هرس از این مقدار بیشتر شود. مقدار پیش‌فرض ۱ است.

man.viewer

برنامه‌هایی را که می‌توان برای نمایش راهنما در قالب man استفاده کرد مشخص می‌کند. ببینید: git-help(1).

man.<tool>.cmd

دستور فراخوانی نمایش‌دهنده man مشخص‌شده را تعیین می‌کند. دستور مشخص‌شده در پوسته با صفحه man که به عنوان یک آرگومان ارسال شده است، ارزیابی می‌گردد. (ببینید: git-help(1).)

man.<tool>.path

مسیر ابزار داده‌شده را که ممکن است برای نمایش راهنما در قالب man استفاده شود لغو و جایگزین می‌کند. ببینید: git-help(1).

merge.conflictStyle

سبکی را که در آن قطعه‌های دچار تعارض هنگام ادغام در فایل‌های درخت کاری نوشته می‌شوند مشخص می‌کند. حالت پیش‌فرض "merge" است که یک نشانگر تعارض <<<<<<<، تغییرات ایجاد شده توسط یک طرف، یک نشانگر =======، تغییرات ایجاد شده توسط طرف دیگر، و سپس یک نشانگر >>>>>>> را نشان می‌دهد. یک سبک جایگزین، "diff3"، یک نشانگر ||||||| و متن اصلی را قبل از نشانگر ======= اضافه می‌کند. سبک "merge" معمولاً نواحی تعارض کوچک‌تری نسبت به diff3 ایجاد می‌کند، هم به دلیل حذف متن اصلی و هم به این دلیل که وقتی زیرمجموعه‌ای از خطوط در هر دو طرف مطابقت دارند، آن‌ها به سادگی از ناحیه تعارض خارج می‌شوند. سبک جایگزین دیگر، "zdiff3"، شبیه به diff3 است اما خطوط منطبق در هر دو طرف را از ناحیه تعارض حذف می‌کند، در صورتی که آن خطوط منطبق در نزدیکی ابتدا یا انتهای یک ناحیه تعارض ظاهر شوند.

merge.defaultToUpstream

اگر merge بدون هیچ آرگومان کامیتی فراخوانی شود، شاخه‌های بالادست (upstream) پیکربندی‌شده برای شاخه فعلی را با استفاده از آخرین مقادیر مشاهده‌شده ذخیره‌شده در شاخه‌های ردیابی ریموت آن‌ها ادغام می‌کند. مقادیر branch.<current branch>.merge که شاخه‌های موجود در ریموت مشخص‌شده توسط branch.<current-branch>.remote را نام می‌برند بررسی شده، و سپس از طریق remote.<remote>.fetch به شاخه‌های ردیابی ریموت متناظرشان نگاشت می‌شوند و نوک (tip) این شاخه‌های ردیابی ادغام می‌گردند. پیش‌فرض روی true است.

merge.ff

به‌طور پیش‌فرض، Git هنگام ادغام کامیتی که از نوادگان کامیت فعلی است، یک کامیت ادغام اضافی ایجاد نمی‌کند. در عوض، نوک شاخه فعلی به‌صورت فوروارد سریع (fast-forward) پیش می‌رود. هنگامی که روی false تنظیم شود، این متغیر به Git می‌گوید در چنین حالتی یک کامیت ادغام اضافی ایجاد کند (معادل ارسال گزینه --no-ff از خط فرمان). هنگامی که روی only تنظیم شود، تنها این‌گونه ادغام‌های فوروارد سریع مجاز هستند (معادل ارسال گزینه --ff-only از خط فرمان).

merge.verifySignatures

اگر true باشد، این معادل گزینه خط فرمان --verify-signatures است. برای جزئیات git-merge(1) را ببینید.

merge.branchdesc

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

merge.log

علاوه بر نام شاخه‌ها، پیام لاگ را حداکثر با تعداد مشخص‌شده‌ای از توضیحات تک‌خطی از کامیت‌های واقعی که در حال ادغام هستند پر می‌کند. پیش‌فرض false است و true مترادف با ۲۰ می‌باشد.

merge.suppressDest

با افزودن یک الگوی عمومی (glob) که با نام‌های شاخه‌های یکپارچه‌سازی تطابق دارد به این متغیر پیکربندی چندمقداری، پیام پیش‌فرض ادغام محاسبه‌شده برای ادغام در این شاخه‌های یکپارچه‌سازی، عبارت "into <branch-name>" را از عنوان خود حذف خواهد کرد.

یک عنصر با مقدار خالی می‌تواند برای پاک کردن فهرست الگوهای عمومی انباشته‌شده از مدخل‌های پیکربندی قبلی استفاده شود. هنگامی که هیچ متغیر merge.suppressDest تعریف نشده باشد، مقدار پیش‌فرض master برای سازگاری با گذشته استفاده می‌شود.

merge.renameLimit

تعداد فایل‌هایی که در بخش جامع تشخیص تغییر نام در حین ادغام باید در نظر گرفته شوند. در صورت عدم تعیین، مقدار پیش‌فرض آن برابر با مقدار diff.renameLimit خواهد بود. اگر نه merge.renameLimit و نه diff.renameLimit مشخص نشده باشند، در حال حاضر مقدار پیش‌فرض ۷۰۰۰ است. این تنظیم در صورت غیرفعال بودن تشخیص تغییر نام هیچ اثری ندارد.

merge.renames

آیا Git تغییر نام‌ها را تشخیص دهد یا خیر. اگر روی false تنظیم شود، تشخیص تغییر نام غیرفعال می‌گردد. اگر روی true تنظیم شود، تشخیص پایه تغییر نام فعال می‌شود. به‌طور پیش‌فرض برابر با مقدار diff.renames است.

merge.directoryRenames

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

false

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

true

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

conflict

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

اگر merge.renames برابر با false باشد، merge.directoryRenames نادیده گرفته شده و مانند false با آن رفتار می‌شود. پیش‌فرض conflict است.

merge.renormalize

به Git اعلام می‌کند که نمایش متعارف فایل‌ها در مخزن در طول زمان تغییر کرده است (به عنوان مثال کامیت‌های قبلی فایل‌های متنی را با پایان خط CRLF ثبت کرده‌اند، اما کامیت‌های اخیر از پایان خط LF استفاده می‌کنند). در چنین مخزنی، برای هر فایلی که در آن به یک ادغام محتوایی سه‌طرفه نیاز است، Git می‌تواند داده‌های ثبت‌شده در کامیت‌ها را قبل از انجام ادغام به یک شکل متعارف تبدیل کند تا تعارض‌های غیرضروری کاهش یابند. برای اطلاعات بیشتر، بخش "Merging branches with differing checkin/checkout attributes" را در gitattributes(5) ببینید.

merge.stat

چه چیزی (در صورت وجود) بین ORIG_HEAD و نتیجه ادغام در پایان ادغام چاپ شود. مقادیر ممکن عبارتند از:

false

چیزی نشان داده نشود.

true

نمایش git diff --diffstat --summary ORIG_HEAD.

compact

نمایش git diff --compact-summary ORIG_HEAD.

اما هر مقدار ناشناخته (مثلاً مقداری که توسط نسخه آینده Git اضافه شده باشد) به جای ایجاد خطا به عنوان true در نظر گرفته می‌شود. پیش‌فرض true است.

merge.autoStash

هنگامی که روی true تنظیم شود، پیش از شروع عملیات به‌طور خودکار یک مدخل موقت استش (stash) ایجاد کرده و پس از پایان عملیات آن را اعمال می‌کند. این بدان معناست که می‌توانید ادغام را روی یک درخت کاری کثیف (دارای تغییرات ثبت‌نشده) اجرا کنید. با این حال، با احتیاط استفاده کنید: اعمال نهایی استش پس از یک ادغام موفقیت‌آمیز ممکن است به تعارض‌های غیرپیش‌پاافتاده منجر شود. این گزینه می‌تواند توسط گزینه‌های --no-autostash و --autostash در git-merge(1) لغو و بازنویسی شود. پیش‌فرض روی false است.

merge.tool

کنترل می‌کند که کدام ابزار ادغام توسط git-mergetool(1) استفاده شود. فهرست زیر مقادیر معتبر توکار را نشان می‌دهد. هر مقدار دیگری به عنوان یک ابزار ادغام سفارشی در نظر گرفته می‌شود و مستلزم آن است که متغیر متناظر mergetool.<tool>.cmd تعریف شده باشد.

merge.guitool

کنترل می‌کند که در زمان مشخص شدن فلگ -g/--gui، کدام ابزار ادغام توسط git-mergetool(1) استفاده شود. فهرست زیر مقادیر معتبر توکار را نشان می‌دهد. هر مقدار دیگری به عنوان یک ابزار ادغام سفارشی در نظر گرفته می‌شود و مستلزم آن است که متغیر متناظر mergetool.<guitool>.cmd تعریف شده باشد.

araxis

استفاده از Araxis Merge (نیازمند نشست گرافیکی)

bc

استفاده از Beyond Compare (نیازمند نشست گرافیکی)

bc3

استفاده از Beyond Compare (نیازمند نشست گرافیکی)

bc4

استفاده از Beyond Compare (نیازمند نشست گرافیکی)

codecompare

استفاده از Code Compare (نیازمند نشست گرافیکی)

deltawalker

استفاده از DeltaWalker (نیازمند نشست گرافیکی)

diffmerge

استفاده از DiffMerge (نیازمند نشست گرافیکی)

diffuse

استفاده از Diffuse (نیازمند نشست گرافیکی)

ecmerge

استفاده از ECMerge (نیازمند نشست گرافیکی)

emerge

استفاده از Emerge در Emacs

examdiff

استفاده از ExamDiff Pro (نیازمند نشست گرافیکی)

guiffy

استفاده از ابزار Diff گویفی (Guiffy) (نیازمند نشست گرافیکی)

gvimdiff

استفاده از gVim (نیازمند نشست گرافیکی) با یک چیدمان سفارشی (بخش BACKEND SPECIFIC HINTS در git help mergetool را ببینید)

gvimdiff1

استفاده از gVim (نیازمند نشست گرافیکی) با چیدمان ۲ پانلی (LOCAL و REMOTE)

gvimdiff2

استفاده از gVim (نیازمند نشست گرافیکی) با چیدمان ۳ پانلی (LOCAL، MERGED و REMOTE)

gvimdiff3

استفاده از gVim (نیازمند نشست گرافیکی) که در آن فقط فایل MERGED نمایش داده می‌شود

kdiff3

استفاده از KDiff3 (نیازمند نشست گرافیکی)

meld

استفاده از Meld (نیازمند نشست گرافیکی) با ادغام خودکار اختیاری (بخش CONFIGURATION در git help mergetool را ببینید)

nvimdiff

استفاده از Neovim با یک چیدمان سفارشی (بخش BACKEND SPECIFIC HINTS در git help mergetool را ببینید)

nvimdiff1

استفاده از Neovim با چیدمان ۲ پانلی (LOCAL و REMOTE)

nvimdiff2

استفاده از Neovim با چیدمان ۳ پانلی (LOCAL، MERGED و REMOTE)

nvimdiff3

استفاده از Neovim که در آن فقط فایل MERGED نمایش داده می‌شود

opendiff

استفاده از FileMerge (نیازمند نشست گرافیکی)

p4merge

استفاده از HelixCore P4Merge (نیازمند نشست گرافیکی)

smerge

استفاده از Sublime Merge (نیازمند نشست گرافیکی)

tkdiff

استفاده از TkDiff (نیازمند نشست گرافیکی)

tortoisemerge

استفاده از TortoiseMerge (نیازمند نشست گرافیکی)

vimdiff

استفاده از Vim با یک چیدمان سفارشی (بخش BACKEND SPECIFIC HINTS در git help mergetool را ببینید)

vimdiff1

استفاده از Vim با چیدمان ۲ پانلی (LOCAL و REMOTE)

vimdiff2

استفاده از Vim با چیدمان ۳ پانلی (LOCAL، MERGED و REMOTE)

vimdiff3

استفاده از Vim که در آن فقط فایل MERGED نمایش داده می‌شود

vscode

استفاده از Visual Studio Code (نیازمند نشست گرافیکی)

winmerge

استفاده از WinMerge (نیازمند نشست گرافیکی)

xxdiff

استفاده از xxdiff (نیازمند نشست گرافیکی)

merge.verbosity

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

merge.<driver>.name

یک نام خوانا برای انسان برای یک راه‌انداز ادغام سطح‌پایین سفارشی تعریف می‌کند. برای جزئیات gitattributes(5) را ببینید.

merge.<driver>.driver

دستوری را که یک راه‌انداز ادغام سطح‌پایین سفارشی را پیاده‌سازی می‌کند تعریف می‌نماید. برای جزئیات gitattributes(5) را ببینید.

merge.<driver>.recursive

نام یک راه‌انداز ادغام سطح‌پایین را تعیین می‌کند که هنگام انجام ادغام داخلی میان نیاکان مشترک استفاده شود. برای جزئیات gitattributes(5) را ببینید.

mergetool.<tool>.path

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

mergetool.<tool>.cmd

دستور فراخوانی ابزار ادغام مشخص‌شده را تعیین می‌کند. دستور مشخص‌شده در پوسته با متغیرهای زیر در دسترس ارزیابی می‌شود: BASE نام یک فایل موقت حاوی پایه مشترک فایل‌های در حال ادغام است (در صورت موجود بودن)؛ LOCAL نام یک فایل موقت حاوی محتویات فایل در شاخه فعلی است؛ REMOTE نام یک فایل موقت حاوی محتویات فایل از شاخه‌ای است که در حال ادغام است؛ MERGED شامل نام فایلی است که ابزار ادغام باید نتایج یک ادغام موفقیت‌آمیز را در آن بنویسد.

mergetool.<tool>.hideResolved

به کاربر اجازه می‌دهد مقدار سراسری mergetool.hideResolved را برای یک ابزار خاص لغو و بازنویسی کند. برای شرح کامل mergetool.hideResolved را ببینید.

mergetool.<tool>.trustExitCode

برای یک دستور ادغام سفارشی، مشخص می‌کند که آیا می‌توان از کد خروج دستور ادغام برای تعیین موفقیت‌آمیز بودن ادغام استفاده کرد یا خیر. اگر این روی true تنظیم نشده باشد، برچسب زمانی فایل مقصد ادغام بررسی می‌شود و در صورتی که فایل به‌روزرسانی شده باشد فرض می‌شود ادغام موفقیت‌آمیز بوده است؛ در غیر این صورت، از کاربر خواسته می‌شود موفقیت ادغام را مشخص کند.

mergetool.meld.hasOutput

نسخه‌های قدیمی‌تر meld از گزینه --output پشتیبانی نمی‌کنند. Git با بررسی خروجی meld --help تلاش خواهد کرد تشخیص دهد که آیا meld از --output پشتیبانی می‌کند یا خیر. پیکربندی mergetool.meld.hasOutput باعث می‌شود Git از این بررسی‌ها صرف‌نظر کرده و در عوض از مقدار پیکربندی‌شده استفاده کند. تنظیم mergetool.meld.hasOutput روی true به Git می‌گوید بدون قیدوشرط از گزینه --output استفاده کند، و false از استفاده از --output خودداری می‌کند.

mergetool.meld.useAutoMerge

هنگامی که گزینه --auto-merge داده می‌شود، meld تمام بخش‌های بدون تعارض را به‌طور خودکار ادغام می‌کند، بخش‌های دارای تعارض را برجسته می‌سازد و منتظر تصمیم کاربر می‌ماند. تنظیم mergetool.meld.useAutoMerge روی true به Git می‌گوید بدون قیدوشرط از گزینه --auto-merge همراه با meld استفاده کند. تنظیم این مقدار روی auto باعث می‌شود git تشخیص دهد که آیا --auto-merge پشتیبانی می‌شود یا خیر و تنها زمانی که در دسترس باشد از --auto-merge استفاده کند. مقدار false به‌طور کلی از استفاده از --auto-merge خودداری می‌کند و مقدار پیش‌فرض است.

mergetool.<variant>.layout

چیدمان پنجره تقسیم‌شده (split window) را برای <variant> مربوط به vimdiff پیکربندی می‌کند، که می‌تواند هر یک از vimdiff، nvimdiff یا gvimdiff باشد. هنگام راه‌اندازی git mergetool با --tool=<variant> (یا بدون --tool اگر merge.tool به عنوان <variant> پیکربندی شده باشد)، Git به mergetool.<variant>.layout مراجعه می‌کند تا چیدمان ابزار را تعیین کند. اگر پیکربندی مخصوص نسخه موجود نباشد، چیدمان vimdiff به عنوان جایگزین استفاده می‌شود. اگر آن هم موجود نباشد، یک چیدمان پیش‌فرض با ۴ پنجره استفاده خواهد شد. برای پیکربندی چیدمان، بخش BACKEND SPECIFIC HINTS را در git-mergetool(1) ببینید.

mergetool.hideResolved

در حین یک ادغام، Git به‌طور خودکار تا حد امکان تعارض‌ها را برطرف کرده و فایل $MERGED را می‌نویسد که حاوی نشانگرهای تعارض در اطراف هر تعارضی است که نتوانسته آن را برطرف کند؛ $LOCAL و $REMOTE به‌طور معمول نسخه‌های فایل از قبل از حل تعارض توسط Git هستند. این فلگ باعث می‌شود $LOCAL و $REMOTE رونویسی شوند تا فقط تعارض‌های حل‌نشده به ابزار ادغام ارائه گردند. می‌تواند برای هر ابزار از طریق متغیر پیکربندی mergetool.<tool>.hideResolved پیکربندی شود. پیش‌فرض روی false است.

mergetool.keepBackup

پس از انجام ادغام، فایل اصلی همراه با نشانگرهای تعارض می‌تواند به عنوان فایلی با پسوند .orig ذخیره شود. اگر این متغیر روی false تنظیم شود، این فایل حفظ نمی‌گردد. پیش‌فرض true است (یعنی فایل‌های پشتیبان نگه‌داری شوند).

mergetool.keepTemporaries

هنگام فراخوانی یک ابزار ادغام سفارشی، Git از مجموعه‌ای از فایل‌های موقت برای ارسال به ابزار استفاده می‌کند. اگر ابزار خطایی بازگرداند و این متغیر روی true تنظیم شده باشد، این فایل‌های موقت حفظ خواهند شد؛ در غیر این صورت، پس از خروج ابزار حذف می‌شوند. پیش‌فرض false است.

mergetool.writeToTemp

به‌طور پیش‌فرض Git نسخه‌های موقت BASE، LOCAL و REMOTE از فایل‌های دارای تعارض را در درخت کاری می‌نویسد. هنگامی که روی true تنظیم شود، Git تلاش خواهد کرد از یک دایرکتوری موقت برای این فایل‌ها استفاده کند. پیش‌فرض false است.

mergetool.prompt

پیش از هر بار فراخوانی برنامه حل تعارض ادغام، اعلان نمایش می‌دهد (تایید می‌گیرد).

mergetool.guiDefault

روی true تنظیم کنید تا به‌طور پیش‌فرض از merge.guitool استفاده شود (معادل مشخص کردن آرگومان --gui)، یا auto تا بسته به وجود مقدار متغیر محیطی DISPLAY، بین merge.guitool یا merge.tool انتخاب شود. مقدار پیش‌فرض false است که در آن آرگومان --gui باید صریحاً ارائه شود تا merge.guitool استفاده گردد.

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

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

این تنظیم را می‌توان با متغیر محیطی GIT_NOTES_DISPLAY_REF که باید فهرستی از مراجع یا الگوهای عمومی جداشده با دو نقطه (:) باشد، لغو و بازنویسی کرد.

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

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

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

notes.rewrite.<command>

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

این تنظیم را می‌توان با متغیر محیطی GIT_NOTES_REWRITE_REF که باید فهرستی از مراجع یا الگوهای عمومی جداشده با دو نقطه (:) باشد، لغو و بازنویسی کرد.

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> را در بالا ببینید.

pack.window

اندازه پنجره مورد استفاده توسط git-pack-objects(1) هنگامی که اندازه پنجره‌ای در خط فرمان داده نشده باشد. پیش‌فرض ۱۰ است.

pack.depth

حداکثر عمق دلتا مورد استفاده توسط git-pack-objects(1) هنگامی که حداکثر عمقی در خط فرمان داده نشده باشد. پیش‌فرض ۵۰ است. حداکثر مقدار ۴۰۹۵ می‌باشد.

pack.windowMemory

حداکثر مقدار حافظه‌ای که توسط هر ریسه (thread) در git-pack-objects(1) برای حافظه پنجره بسته مصرف می‌شود، در صورتی که هیچ محدودیتی در خط فرمان داده نشده باشد. مقدار می‌تواند با پسوندهای "k"، "m" یا "g" همراه باشد. هنگامی که پیکربندی نشود (یا صریحاً روی 0 تنظیم شود)، هیچ محدودیتی وجود نخواهد داشت.

pack.compression

یک عدد صحیح بین -1..9، که سطح فشرده‌سازی اشیاء را در یک فایل بسته (pack file) مشخص می‌کند. -1 پیش‌فرض zlib است. مقدار 0 به معنای عدم فشرده‌سازی است، و 1..9 موازنه‌های مختلف میان سرعت و اندازه هستند که 9 کندترین آن‌هاست. اگر تنظیم نشود، به صورت پیش‌فرض core.compression در نظر گرفته می‌شود. اگر آن هم تنظیم نشده باشد، مقدار پیش‌فرض -1 (پیش‌فرض zlib) خواهد بود، که «یک سازش پیش‌فرض میان سرعت و فشرده‌سازی است (در حال حاضر معادل سطح 6)».

توجه داشته باشید که تغییر سطح فشرده‌سازی به‌طور خودکار تمام اشیاء موجود را مجدداً فشرده نمی‌کند. می‌توانید با دادن گزینه -F به git-repack(1) فشرده‌سازی مجدد را اجبار کنید.

pack.allowPackReuse

هنگامی که روی true یا "single" تنظیم شده باشد، و بیت‌مپ‌های دسترسی‌پذیری فعال باشند، pack-objects تلاش خواهد کرد بخش‌هایی از فایل بسته دارای بیت‌مپ را عیناً ارسال کند. هنگامی که روی "multi" تنظیم شده باشد، و یک بیت‌مپ دسترسی‌پذیری چندبسته‌ای در دسترس باشد، pack-objects تلاش خواهد کرد بخش‌هایی از تمام بسته‌ها را در MIDX ارسال کند.

اگر فقط یک بیت‌مپ بسته تکی در دسترس باشد، و pack.allowPackReuse روی "multi" تنظیم شده باشد، تنها بخش‌هایی از همان فایل بسته دارای بیت‌مپ مجدداً استفاده می‌شود. این کار می‌تواند مصرف حافظه و پردازنده را برای پاسخ به واکشی‌ها کاهش دهد، اما ممکن است منجر به ارسال بسته‌ای کمی بزرگ‌تر شود. مقدار پیش‌فرض true است.

pack.island

یک عبارت باقاعده گسترش‌یافته (extended regular expression) برای پیکربندی مجموعه‌ای از جزیره‌های دلتا (delta islands). برای جزئیات به بخش "DELTA ISLANDS" در git-pack-objects(1) مراجعه کنید.

pack.islandCore

نام جزیره‌ای را مشخص می‌کند که اشیاء آن باید در ابتدا بسته‌بندی شوند. این کار نوعی شبه‌بسته (pseudo-pack) در ابتدای یک بسته ایجاد می‌کند، به‌طوری‌که اشیاء متعلق به جزیره مشخص‌شده با سرعت بیشتری در هر بسته‌ای که قرار است برای کاربری که آن اشیاء را درخواست کرده ارسال شود، کپی شوند. در عمل این بدان معناست که جزیره مشخص‌شده احتمالاً باید با آنچه معمولاً در مخزن کلون می‌شود مطابقت داشته باشد. همچنین به "DELTA ISLANDS" در git-pack-objects(1). مراجعه کنید.

pack.deltaCacheSize

حداکثر حافظه بر حسب بایت که برای کش کردن دلتاها در git-pack-objects(1) قبل از نوشتن آن‌ها در یک بسته استفاده می‌شود. این کش برای افزایش سرعت مرحله نوشتن اشیاء استفاده می‌شود تا پس از یافتن بهترین تطابق برای تمام اشیاء، نیازی به محاسبه مجدد نتیجه نهایی دلتا نباشد. البته بسته‌بندی مجدد مخازن بزرگ در دستگاه‌هایی با حافظه محدود ممکن است از این امر به شدت متأثر شود، به‌ویژه اگر این کش سیستم را به فضای مبادله (swapping) بکشاند. مقدار 0 به معنای عدم وجود محدودیت است. کوچک‌ترین اندازه یعنی 1 بایت می‌تواند برای غیرفعال کردن مجازی این کش استفاده شود. مقدار پیش‌فرض 256 MiB است.

pack.deltaCacheLimit

حداکثر اندازه یک دلتا که در git-pack-objects(1). کش می‌شود. این کش برای افزایش سرعت مرحله نوشتن شیء استفاده می‌شود تا پس از یافتن بهترین تطابق برای همه اشیاء، نیازی به محاسبه مجدد نتیجه دلتای نهایی نباشد. مقدار پیش‌فرض 1000 است. حداکثر مقدار 65535 می‌باشد.

pack.threads

تعداد ریسمان‌هایی (threads) را مشخص می‌کند که هنگام جستجو برای بهترین تطابق‌های دلتا ایجاد می‌شوند. این نیازمند آن است که git-pack-objects(1) با پشتیبانی از pthreads کامپایل شده باشد، در غیر این صورت این گزینه با نمایش یک هشدار نادیده گرفته می‌شود. این کار برای کاهش زمان بسته‌بندی در ماشین‌های چندپردازنده‌ای در نظر گرفته شده است. با این حال، مقدار حافظه مورد نیاز برای پنجره جستجوی دلتا در تعداد ریسمان‌ها ضرب می‌شود. تعیین مقدار 0 باعث می‌شود Git تعداد پردازنده‌ها را به‌طور خودکار تشخیص داده و تعداد ریسمان‌ها را متناسب با آن تنظیم کند.

pack.indexVersion

نسخه پیش‌فرض ایندکس بسته را مشخص می‌کند. مقادیر معتبر عبارتند از 1 برای ایندکس بسته قدیمی که توسط نسخه‌های Git قبل از 1.5.2 استفاده می‌شد، و 2 برای ایندکس بسته جدید با قابلیت پشتیبانی از بسته‌های بزرگ‌تر از 4 گیگابایت و همچنین محافظت مناسب در برابر بسته‌بندی مجدد بسته‌های خراب. نسخه 2 پیش‌فرض است. توجه داشته باشید که هر زمان بسته مربوطه بزرگ‌تر از 2 گیگابایت باشد، نسخه 2 اجباری شده و این گزینه پیکربندی نادیده گرفته می‌شود.

اگر نسخه قدیمی Git را دارید که فایل *.idx نسخه 2 را درک نمی‌کند، کلون کردن یا واکشی از طریق یک پروتکل غیربومی (مانند "http") که هر دو فایل *.pack و فایل مربوطه *.idx را از طرف دیگر کپی می‌کند، ممکن است مخزنی به شما بدهد که با نسخه قدیمی‌تر Git شما قابل دسترسی نباشد. اما اگر فایل *.pack کوچک‌تر از 2 گیگابایت باشد، می‌توانید از git-index-pack(1) روی فایل *.pack برای تولید مجدد فایل *.idx استفاده کنید.

pack.packSizeLimit

حداکثر اندازه یک بسته. این تنظیم فقط روی بسته‌بندی در یک فایل هنگام بسته‌بندی مجدد تأثیر می‌گذارد، یعنی پروتکل git:// تحت تأثیر قرار نمی‌گیرد. این گزینه می‌تواند با گزینه --max-pack-size از دستور git-repack(1) بازنویسی شود. رسیدن به این محدودیت منجر به ایجاد چندین فایل بسته می‌شود.

توجه داشته باشید که این گزینه به ندرت مفید است و ممکن است منجر به افزایش اندازه کل روی دیسک (زیرا Git دلتاها را میان بسته‌ها ذخیره نمی‌کند) و کارایی ضعیف‌تر در زمان اجرا شود (جستجوی اشیاء در چندین بسته کندتر از یک بسته است، و بهینه‌سازی‌هایی مانند بیت‌مپ‌های دسترسی‌پذیری نمی‌توانند با چند بسته سازگار شوند).

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

حداقل اندازه مجاز به 1 MiB محدود شده است. پیش‌فرض نامحدود است. پسوندهای رایج واحد k، m، یا g پشتیبانی می‌شوند.

pack.useBitmaps

هنگامی که روی true تنظیم شود، git هنگام بسته‌بندی در stdout (مانند زمان سمت سرور در یک واکشی) از بیت‌مپ‌های بسته (در صورت موجود بودن) استفاده خواهد کرد. مقدار پیش‌فرض true است. به‌طور کلی نباید نیازی به خاموش کردن این گزینه داشته باشید، مگر اینکه در حال اشکال‌زدایی بیت‌مپ‌های بسته باشید.

pack.useBitmapBoundaryTraversal

هنگامی که روی true تنظیم شود، Git از یک الگوریتم آزمایشی برای محاسبه پرس‌وجوهای دسترسی‌پذیری با بیت‌مپ‌ها استفاده خواهد کرد. به جای ساخت بیت‌مپ‌های کامل برای تمام سرشاخه‌های منفی‌شده (negated tips) و سپس اعمال عملگر OR بین آن‌ها، سرشاخه‌های منفی‌شده با بیت‌مپ‌های موجود را افزایشی در نظر می‌گیرد (یعنی اگر وجود داشته باشند، آن‌ها را در نتیجه OR می‌کند و در غیر این صورت از آن‌ها صرف‌نظر می‌کند)، و در عوض یک بیت‌مپ در مرز می‌سازد.

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

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

pack.useSparse

هنگامی که روی true تنظیم شود، git به طور پیش‌فرض هنگام حضور گزینه --sparse از گزینه --sparse در git pack-objects استفاده خواهد کرد. این الگوریتم تنها درخت‌هایی را پیمایش می‌کند که در مسیرهای معرفی‌کننده اشیاء جدید ظاهر می‌شوند. این کار می‌تواند هنگام محاسبه یک بسته برای ارسال تغییری کوچک، مزایای عملکردی چشمگیری داشته باشد. با این حال، اگر کامیت‌های شامل‌شده دارای انواع خاصی از تغییر نام‌های مستقیم باشند، ممکن است اشیاء اضافی به فایل بسته افزوده شوند. پیش‌فرض true است.

pack.usePathWalk

گزینه --path-walk را به صورت پیش‌فرض برای فرآیندهای git pack-objects فعال می‌کند. برای جزئیات کامل به git-pack-objects(1) مراجعه کنید.

pack.preferBitmapTips

یک سلسله‌مراتب مرجع (ref hierarchy) را مشخص می‌کند (مانند "refs/heads/")؛ می‌تواند چند بار برای مشخص کردن بیش از یک سلسله‌مراتب داده شود. هنگام انتخاب اینکه کدام کامیت‌ها بیت‌مپ دریافت کنند، کامیتی که در سرشاخه (tip) مرجعی قرار دارد که در هر یک از سلسله‌مراتب‌های پیکربندی‌شده گنجانده شده است، در اولویت قرار می‌گیرد.

توجه داشته باشید که تنظیم این پیکربندی روی refs/foo/ به این معنی نیست که کامیت‌های موجود در سرشاخه‌های refs/foo/bar و refs/foo/baz لزوماً انتخاب خواهند شد. دلیل این امر آن است که کامیت‌ها برای بیت‌مپ‌ها از میان مجموعه‌ای از پنجره‌های با طول متغیر انتخاب می‌شوند.

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

pack.writeBitmaps (منسوخ‌شده)

این یک مترادف منسوخ‌شده برای repack.writeBitmaps است.

pack.writeBitmapHashCache

هنگامی که روی true تنظیم شود، git بخشی تحت عنوان "hash cache" را در ایندکس بیت‌مپ (در صورت نوشته شدن) شامل خواهد کرد. این کش می‌تواند برای تغذیه قواعد مکاشفه‌ای دلتا در git استفاده شود، که بالقوه منجر به دلتاهای بهتری میان اشیاء دارای بیت‌مپ و فاقد بیت‌مپ می‌شود (برای مثال، هنگام پاسخ‌گویی به یک واکشی میان یک بسته قدیمی‌تر دارای بیت‌مپ و اشیائی که پس از آخرین gc پوش شده‌اند). عیب آن این است که 4 بایت به ازای هر شیء از فضای دیسک را مصرف می‌کند. مقدار پیش‌فرض true است.

هنگام نوشتن یک بیت‌مپ دسترسی‌پذیری چندبسته‌ای، هیچ namehash جدیدی محاسبه نمی‌شود؛ در عوض، هر namehash ذخیره‌شده در یک بیت‌مپ موجود هنگام نوشتن یک بیت‌مپ جدید به مکان مناسب خود جابه‌جا (permuted) می‌شود.

pack.writeBitmapLookupTable

هنگامی که روی true تنظیم شود، Git بخشی تحت عنوان "lookup table" (جدول جستجو) را در ایندکس بیت‌مپ (در صورت نوشته شدن) می‌گنجاند. این جدول برای به تعویق انداختن بارگذاری بیت‌مپ‌های منفرد تا جای ممکن استفاده می‌شود. این کار می‌تواند در مخازنی که ایندکس‌های بیت‌مپ نسبتاً بزرگی دارند سودمند باشد. مقدار پیش‌فرض false است.

pack.readReverseIndex

هنگامی که روی true تنظیم شود، git هر فایل .rev موجود را می‌خواند (ببینید: gitformat-pack(5)). هنگامی که روی false باشد، ایندکس معکوس از ابتدا تولید شده و در حافظه ذخیره می‌شود. مقدار پیش‌فرض true است.

pack.writeReverseIndex

هنگامی که روی true تنظیم شود، git برای هر فایل بسته جدیدی که می‌نویسد، یک فایل .rev متناظر می‌نویسد (ببینید: gitformat-pack(5))، در همه جا به جز در git-fast-import(1) و در سازوکار ثبت فله‌ای (bulk checkin). مقدار پیش‌فرض true است.

pager.<cmd>

اگر مقدار یک بولی باشد، صفحه‌بندی خروجی یک زیردستور خاص Git را هنگام نوشتن در tty روشن یا خاموش می‌کند. در غیر این صورت، صفحه‌بندی را برای آن زیردستور با استفاده از صفحه‌بندی‌کننده‌ای (pager) که مقدار pager.<cmd> مشخص کرده فعال می‌کند. اگر --paginate یا --no-pager در خط فرمان مشخص شود، بر این گزینه اولویت دارد. برای غیرفعال کردن صفحه‌بندی برای همه دستورات، core.pager یا GIT_PAGER را روی cat تنظیم کنید.

pretty.<name>

نام مستعار برای یک رشته قالب --pretty=، همان‌طور که در git-log(1) مشخص شده است. هر نام مستعاری که در اینجا تعریف شود می‌تواند درست مانند قالب‌های تزیینی (pretty formats) توکار استفاده شود. برای مثال، اجرای git config pretty.changelog "format:* %H %s" باعث می‌شود که فراخوانی git log --pretty=changelog معادل اجرای git log "--pretty=format:* %H %s" باشد. توجه داشته باشید که نام مستعار هم‌نام با یک قالب توکار، بدون هیچ پیامی نادیده گرفته خواهد شد.

promisor.quiet

اگر روی "true" تنظیم شود، هنگام واکشی اشیاء اضافی برای یک کلون جزئی (partial clone)، گزینه --quiet فرض می‌شود.

promisor.advertise

اگر روی "true" تنظیم شود، یک سرور از قابلیت "promisor-remote" (ببینید: gitprotocol-v2(5)) برای اعلان ریموت‌های promisor که استفاده می‌کند (در صورت وجود) استفاده خواهد کرد. مقدار پیش‌فرض "false" است، به این معنی که قابلیت "promisor-remote" اعلان نمی‌شود.

promisor.sendFields

فهرستی از نام‌های فیلدهای اضافی مرتبط با ریموت که با کاما یا فاصله از هم جدا شده‌اند. سرور هنگام اعلان ریموت‌های promisor خود با استفاده از قابلیت "promisor-remote" (ببینید: gitprotocol-v2(5))، این نام‌های فیلد و مقادیر مرتبط با آن‌ها را از پیکربندی خود ارسال می‌کند. در حال حاضر، تنها نام‌های فیلد "partialCloneFilter" و "token" پشتیبانی می‌شوند.

partialCloneFilter

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

token

شامل یک توکن احراز هویت برای ریموت است.

هنگامی که یک نام فیلد بخشی از این فهرست باشد و متغیر پیکربندی متناظر "remote.foo.<field-name>" در سرور روی مقداری غیرخالی تنظیم شده باشد، آنگاه نام و مقدار فیلد هنگام اعلان ریموت promisor با نام "foo" ارسال می‌شوند.

این فهرست هیچ اثری ندارد مگر اینکه متغیر پیکربندی "promisor.advertise" روی "true" تنظیم شده باشد، و فیلدهای "name" و "url" همیشه فارغ از این تنظیم اعلان می‌شوند.

promisor.acceptFromServer

اگر روی "all" تنظیم شود، کلاینت تمام ریموت‌های promisor را که ممکن است سرور با استفاده از قابلیت "promisor-remote" اعلان کند می‌پذیرد. اگر روی "knownName" تنظیم شود، کلاینت ریموت‌های promisor را که از قبل روی کلاینت پیکربندی شده‌اند و نامی یکسان با موارد اعلان‌شده دارند می‌پذیرد. این حالت چندان امن نیست، اما می‌تواند در یک ساختار شرکتی که به سرورها و کلاینت‌ها برای تغییر ندادن نام و URLها اعتماد وجود دارد استفاده شود. اگر روی "knownUrl" تنظیم شود، کلاینت ریموت‌های promisor را می‌پذیرد که هم نام و هم URL یکسانی در کلاینت با نام و URL اعلان‌شده توسط سرور داشته باشند. این حالت از "all" یا "knownName" امن‌تر است، بنابراین در صورت امکان باید به جای آن گزینه‌ها استفاده شود. مقدار پیش‌فرض "none" است، به این معنی که هیچ ریموت promisor اعلان‌شده توسط سرور پذیرفته نخواهد شد. با پذیرش یک ریموت promisor، کلاینت موافقت می‌کند که سرور ممکن است اشیائی را که می‌توان آن‌ها را به‌صورت تنبل (lazily) از این ریموت promisor واکشی کرد، از پاسخ‌های خود به درخواست‌های "fetch" و "clone" از سوی کلاینت حذف کند. مقایسه‌های نام و URL به حروف بزرگ و کوچک حساس هستند. ببینید: gitprotocol-v2(5).

promisor.checkFields

فهرستی از نام‌های فیلدهای اضافی مرتبط با ریموت که با کاما یا فاصله از هم جدا شده‌اند. کلاینت پیش از پذیرش یک ریموت promisor بررسی می‌کند که آیا مقادیر این فیلدها که توسط یک سرور ارسال شده‌اند با مقادیر این فیلدها در پیکربندی خود مطابقت دارند یا خیر. در حال حاضر، "partialCloneFilter" و "token" تنها نام‌های فیلد پشتیبانی‌شده هستند.

اگر یکی از این نام‌های فیلد (مثلاً "token") برای یک ریموت promisor اعلان‌شده (مثلاً "foo") در حال بررسی باشد، سه شرط باید برقرار باشد تا بررسی این فیلد خاص پذیرفته شود:

1.پیکربندی محلی متناظر (مثلاً remote.foo.token) باید تنظیم شده باشد.
2.سرور باید فیلد "token" را برای ریموت "foo" اعلان کند.
3.مقدار پیکربندی محلی remote.foo.token باید دقیقاً با مقدار اعلان‌شده توسط سرور برای فیلد "token" مطابقت داشته باشد.

اگر هر یک از این شرایط برای هر نام فیلد فهرست‌شده در promisor.checkFields برقرار نباشد، ریموت اعلان‌شده "foo" رد می‌شود.

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

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

فیلدهای "name" و "url" همیشه بر اساس سیاست promisor.acceptFromServer و مستقل از این تنظیم بررسی می‌شوند.

نام‌ها و مقادیر فیلدها باید از طریق قابلیت "promisor-remote" توسط سرور با استفاده از متغیر پیکربندی promisor.sendFields ارسال شوند. این فیلدها تنها در صورتی بررسی می‌شوند که متغیر پیکربندی promisor.acceptFromServer روی "None" تنظیم نشده باشد. در صورت تنظیم روی "None"، این متغیر پیکربندی هیچ اثری ندارد. ببینید: gitprotocol-v2(5).

promisor.storeFields

فهرستی از نام‌های فیلدهای اضافی مرتبط با ریموت که با کاما یا فاصله از هم جدا شده‌اند. اگر کلاینت یک ریموت اعلان‌شده را بپذیرد، مقادیر مرتبط با این نام‌های فیلد برگرفته از اعلان ریموت را در پیکربندی خود ذخیره کرده و سپس پیکربندی ریموت خود را مجدداً بارگذاری می‌کند. در حال حاضر، "partialCloneFilter" و "token" تنها نام‌های فیلد پشتیبانی‌شده هستند.

برای مثال، اگر سرور "partialCloneFilter=blob:limit=20k" را برای ریموت "foo" اعلان کند و آن ریموت پذیرفته شود، آنگاه "blob:limit=20k" برای متغیر پیکربندی "remote.foo.partialCloneFilter" ذخیره خواهد شد.

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

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

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

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

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

protocol.allow

در صورت تنظیم، یک سیاست پیش‌فرض تعریف‌شده توسط کاربر برای تمام پروتکل‌هایی که صراحتاً سیاستی ندارند (protocol.<name>.allow) فراهم می‌کند. به‌طور پیش‌فرض در صورت تنظیم نشدن، پروتکل‌های شناخته‌شده به عنوان امن (http، https، git، ssh) دارای سیاست پیش‌فرض always، پروتکل‌های شناخته‌شده به عنوان خطرناک (ext) دارای سیاست پیش‌فرض never، و سایر پروتکل‌ها (از جمله file) دارای سیاست پیش‌فرض user هستند. سیاست‌های پشتیبانی‌شده:
•always - پروتکل همیشه قابل استفاده است.
•never - پروتکل هرگز قابل استفاده نیست.
•user - پروتکل تنها زمانی قابل استفاده است که GIT_PROTOCOL_FROM_USER یا تنظیم نشده باشد یا مقدار 1 داشته باشد. این سیاست باید زمانی استفاده شود که می‌خواهید پروتکل مستقیماً توسط کاربر قابل استفاده باشد اما نمی‌خواهید توسط دستوراتی که دستورات clone/fetch/push را بدون ورودی کاربر اجرا می‌کنند (مانند مقداردهی اولیه بازگشتی زیرماژول‌ها) استفاده شود.

protocol.<name>.allow

سیاستی را برای استفاده توسط پروتکل <name> با دستورات clone/fetch/push تنظیم می‌کند. برای سیاست‌های موجود، به protocol.allow در بالا مراجعه کنید.

نام‌های پروتکل‌هایی که در حال حاضر توسط git استفاده می‌شوند عبارتند از:

•file: هر مسیر مبتنی بر فایل محلی (شامل نشانی‌های file:// یا مسیرهای محلی)
•git: پروتکل ناشناس git روی یک اتصال مستقیم TCP (یا پروکسی، در صورت پیکربندی)
•ssh: پروتکل git روی ssh (شامل ساختار host:path، ssh:// و غیره).
•http: پروتکل git روی http، هم "smart http" و هم "dumb http". توجه داشته باشید که این شامل https نمی‌شود؛ اگر می‌خواهید هر دو را پیکربندی کنید، باید این کار را جداگانه انجام دهید.
•هر کمک‌کننده خارجی با پروتکل خود نام‌گذاری می‌شود (برای مثال، از hg برای مجاز کردن کمک‌کننده git-remote-hg استفاده کنید)

protocol.version

در صورت تنظیم، کلاینت‌ها تلاش خواهند کرد با استفاده از نسخه مشخص‌شده پروتکل با سرور ارتباط برقرار کنند. اگر سرور از آن پشتیبانی نکند، ارتباط به نسخه 0 تنزل می‌یابد. در صورت تنظیم نشدن، پیش‌فرض 2 است. نسخه‌های پشتیبانی‌شده:
•0 - پروتکل مخابره‌ای (wire protocol) اصلی.
•1 - پروتکل مخابره‌ای اصلی با اضافه شدن یک رشته نسخه در پاسخ اولیه از سرور.
•2 - نسخه 2 پروتکل مخابره‌ای، ببینید: gitprotocol-v2(5).

pull.ff

به‌طور پیش‌فرض، Git هنگام ادغام کامیتی که از نوادگان کامیت فعلی است، کامیت ادغام اضافی ایجاد نمی‌کند. در عوض، سرشاخه شاخه فعلی به جلو رانده می‌شود (fast-forward). هنگامی که روی false تنظیم شود، این متغیر به Git می‌گوید که در چنین مواردی یک کامیت ادغام اضافی ایجاد کند (معادل دادن گزینه --no-ff از خط فرمان). هنگامی که روی only تنظیم شود، فقط چنین ادغام‌های رو به جلویی (fast-forward) مجاز هستند (معادل دادن گزینه --ff-only از خط فرمان). این تنظیم در زمان اجرای pull، گزینه merge.ff را بازنویسی می‌کند.

pull.rebase

هنگامی که true باشد، هنگام اجرای "git pull"، شاخه‌ها به جای ادغام با شاخه پیش‌فرض از ریموت پیش‌فرض، بر روی شاخه واکشی‌شده ریبیس (rebase) می‌شوند. برای تنظیم این مورد برای هر شاخه به صورت جداگانه، به "branch.<name>.rebase" مراجعه کنید.

هنگامی که روی merges (یا فقط m) تنظیم شود، گزینه --rebase-merges به git rebase داده می‌شود تا کامیت‌های ادغام محلی در ریبیس گنجانده شوند (برای جزئیات به git-rebase(1) مراجعه کنید).

هنگامی که مقدار interactive (یا فقط i) باشد، ریبیس در حالت تعاملی اجرا می‌شود.

نکته: این عملیاتی احتمالاً خطرناک است؛ از آن استفاده نکنید مگر اینکه از پیامدهای آن آگاه باشید (برای جزئیات به git-rebase(1) مراجعه کنید).

pull.octopus

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

pull.autoStash

هنگامی که روی true تنظیم شود، پیش از شروع عملیات به‌طور خودکار یک مدخل موقت در اندوخته (stash) ایجاد می‌کند تا تغییرات محلی را ثبت کند، و پس از اتمام عملیات آن‌ها را بازیابی می‌کند. زمانی که "git pull" شما ریبیس انجام می‌دهد (به جای ادغام)، این کار می‌تواند بسیار مفید باشد؛ زیرا بر خلاف پول مبتنی بر ادغام که تغییرات محلی بدون تداخل با ادغام را تحمل می‌کند، پول مبتنی بر ریبیس از کار با هرگونه تغییر محلی خودداری می‌کند.

اگر pull.autostash تنظیم شده باشد (چه روی true و چه false)، گزینه‌های merge.autostash و rebase.autostash نادیده گرفته می‌شوند. اگر pull.autostash اصلاً تنظیم نشده باشد، بسته به مقدار pull.rebase، به جای آن از merge.autostash یا rebase.autostash استفاده می‌شود. می‌تواند توسط گزینه خط فرمان --[no-]autostash بازنویسی شود.

pull.twohead

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

push.autoSetupRemote

اگر روی true تنظیم شود، هنگام پوش پیش‌فرض در شرایطی که هیچ ردیابی بالادستی (upstream tracking) برای شاخه فعلی وجود ندارد، گزینه --set-upstream را فرض می‌کند؛ این گزینه با مقادیر simple، upstream و current از تنظیم push.default اثر می‌گذارد. این تنظیم زمانی مفید است که بخواهید شاخه‌های جدید به‌طور پیش‌فرض به ریموت پیش‌فرض پوش شوند (مانند رفتار push.default=current) و همچنین بخواهید ردیابی بالادست تنظیم گردد. جریان‌های کاری که بیشترین بهره را از این گزینه می‌برند، جریان‌های کاری متمرکز simple هستند که در آن‌ها انتظار می‌رود تمام شاخه‌ها نام یکسانی در ریموت داشته باشند.

push.default

عملیاتی را تعریف می‌کند که git push در صورت مشخص نشدن هیچ مشخصه مرجعی (refspec) (چه از خط فرمان، چه پیکربندی یا جای دیگر) باید انجام دهد. مقادیر مختلف برای جریان‌های کاری خاصی مناسب هستند؛ برای مثال، در یک جریان کاری کاملاً متمرکز (یعنی منبع واکشی با مقصد پوش یکسان است)، احتمالاً upstream همان چیزی است که می‌خواهید. مقادیر ممکن عبارتند از:

nothing

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

current

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

upstream

شاخه فعلی را به شاخه‌ای که تغییراتش معمولاً در شاخه فعلی ادغام می‌شوند (که @{upstream} نامیده می‌شود) برمی‌گرداند و پوش می‌کند. این حالت تنها در صورتی منطقی است که به همان مخزنی پوش می‌کنید که معمولاً از آن پول می‌کنید (یعنی جریان کاری متمرکز).

tracking

این یک مترادف منسوخ‌شده برای upstream است.

simple

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

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

این حالت از نسخه Git 2.0 پیش‌فرض است، و امن‌ترین گزینه مناسب برای مبتدیان است.

matching

تمام شاخه‌هایی را که نام یکسانی در هر دو طرف دارند پوش می‌کند. این باعث می‌شود مخزنی که به آن پوش می‌کنید، مجموعه شاخه‌هایی را که پوش می‌شوند به خاطر بسپارد (برای مثال اگر همیشه maint و master را به آنجا پوش کنید و هیچ شاخه دیگری را پوش نکنید، مخزنی که به آن پوش می‌کنید دارای این دو شاخه خواهد بود و شاخه‌های محلی maint و master شما به آنجا پوش خواهند شد).

برای استفاده مؤثر از این حالت، باید مطمئن شوید که تمام شاخه‌هایی که می‌خواهید پوش کنید، قبل از اجرای git push آماده پوش شدن هستند؛ زیرا کل هدف این حالت این است که به شما امکان دهد تمام شاخه‌ها را یک‌باره پوش کنید. اگر معمولاً کار روی تنها یک شاخه را تمام کرده و نتیجه را پوش می‌کنید در حالی که سایر شاخه‌ها ناتمام هستند، این حالت مناسب شما نیست. همچنین این حالت برای پوش کردن به یک مخزن متمرکز اشتراکی مناسب نیست، زیرا ممکن است افراد دیگر شاخه‌های جدیدی در آنجا اضافه کنند، یا سرشاخه شاخه‌های موجود را خارج از کنترل شما به‌روزرسانی کنند.

این حالت قبلاً پیش‌فرض بود، اما از Git 2.0 به بعد این‌گونه نیست (simple پیش‌فرض جدید است).

push.followTags

اگر روی true تنظیم شود، گزینه --follow-tags را به صورت پیش‌فرض فعال می‌کند. می‌توانید این پیکربندی را در زمان پوش با مشخص کردن --no-follow-tags بازنویسی کنید.

push.gpgSign

می‌تواند روی یک مقدار بولی، یا رشته if-asked تنظیم شود. مقدار true باعث می‌شود تمام پوش‌ها با GPG امضا شوند، گویی که --signed به git-push(1) داده شده است. رشته if-asked باعث می‌شود پوش‌ها در صورتی که سرور از آن پشتیبانی کند امضا شوند، گویی که --signed=if-asked به git push داده شده است. مقدار false می‌تواند مقداری از یک فایل پیکربندی با اولویت پایین‌تر را بازنویسی کند. یک فلگ صریح خط فرمان همیشه این گزینه پیکربندی را بازنویسی می‌کند.

push.pushOption

هنگامی که هیچ آرگومان --push-option=<option> از خط فرمان داده نشود، git push طوری عمل می‌کند که گویی هر <option> از این متغیر به صورت --push-option=<option> داده شده است.

این یک متغیر چندمقداری است، و می‌توان از یک مقدار خالی در یک فایل پیکربندی با اولویت بالاتر (مانند .git/config در یک مخزن) برای پاک کردن مقادیر به ارث رسیده از فایل‌های پیکربندی با اولویت پایین‌تر (مانند $HOME/.gitconfig) استفاده کرد.

مثال:
/etc/gitconfig
  push.pushoption = a
  push.pushoption = b
~/.gitconfig
  push.pushoption = c
repo/.git/config
  push.pushoption =
  push.pushoption = b
این تنها منجر به b خواهد شد (a و c پاک می‌شوند).

push.recurseSubmodules

می‌تواند check، on-demand، only، یا no باشد، با همان رفتاری که push --recurse-submodules دارد. در صورت تنظیم نشدن، به‌طور پیش‌فرض no استفاده می‌شود، مگر اینکه submodule.recurse تنظیم شده باشد (که در این صورت، مقدار true به معنی on-demand است).

push.useForceIfIncludes

اگر روی true تنظیم شود، معادل مشخص کردن --force-if-includes به عنوان یک گزینه برای git-push(1) در خط فرمان است. افزودن --no-force-if-includes در زمان پوش، این تنظیم پیکربندی را بازنویسی می‌کند.

push.negotiate

اگر روی true تنظیم شود، تلاش می‌کند اندازه فایل بسته ارسالی را از طریق دورهایی از مذاکره کاهش دهد که در آن کلاینت و سرور سعی می‌کنند کامیت‌های مشترک را پیدا کنند. اگر false باشد، Git برای یافتن کامیت‌های مشترک صرفاً به اعلان مرجع‌های سرور متکی خواهد بود.

push.useBitmaps

اگر روی false تنظیم شود، استفاده از بیت‌مپ‌ها را برای git push غیرفعال می‌کند حتی اگر pack.useBitmaps روی true باشد، بدون آنکه مانع استفاده سایر عملیات‌های git از بیت‌مپ‌ها شود. پیش‌فرض true است.

rebase.backend

بک‌اند (پایانه پشتی) پیش‌فرض برای استفاده در ریبیس. گزینه‌های ممکن عبارتند از apply یا merge. در آینده، اگر بک‌اند merge تمام قابلیت‌های باقی‌مانده بک‌اند apply را به دست آورد، این تنظیم ممکن است بدون استفاده شود.

rebase.stat

آیا آمار تغییرات (diffstat) آنچه از آخرین ریبیس در بالادست تغییر کرده نشان داده شود یا خیر. به‌طور پیش‌فرض false است.

rebase.autoSquash

اگر روی true تنظیم شود، گزینه --autosquash از git-rebase(1) را به‌طور پیش‌فرض برای حالت تعاملی فعال می‌کند. این گزینه می‌تواند با گزینه --no-autosquash بازنویسی شود.

rebase.autoStash

هنگامی که روی true تنظیم شود، پیش از شروع عملیات به‌طور خودکار یک مدخل موقت در اندوخته (stash) ایجاد کرده و پس از پایان عملیات آن را اعمال می‌کند. این بدان معناست که می‌توانید ریبیس را روی یک درخت کاری دارای تغییرات ثبت‌نشده (dirty worktree) اجرا کنید. با این حال با احتیاط استفاده کنید: اعمال نهایی اندوخته پس از یک ریبیس موفق ممکن است به تعارض‌های غیرجزئی منجر شود. این گزینه می‌تواند توسط گزینه‌های --no-autostash و --autostash از git-rebase(1) بازنویسی شود. پیش‌فرض false است.

rebase.updateRefs

اگر روی true تنظیم شود، گزینه --update-refs را به‌طور پیش‌فرض فعال می‌کند.

rebase.missingCommitsCheck

اگر روی "warn" تنظیم شود، git rebase -i در صورت حذف شدن برخی از کامیت‌ها (مثلاً یک خط حذف شده باشد) یک هشدار چاپ می‌کند، اما ریبیس همچنان ادامه خواهد یافت. اگر روی "error" تنظیم شود، هشدار قبلی را چاپ کرده و ریبیس را متوقف می‌کند؛ سپس می‌توان از git rebase --edit-todo برای تصحیح خطا استفاده کرد. اگر روی "ignore" تنظیم شود، هیچ بررسی‌ای انجام نمی‌شود. برای کنار گذاشتن یک کامیت بدون هشدار یا خطا، از دستور drop در فهرست کارهای انجام‌شدنی (todo list) استفاده کنید. مقدار پیش‌فرض "ignore" است.

rebase.instructionFormat

یک رشته قالب، همان‌طور که در git-log(1) مشخص شده است، برای استفاده در فهرست کارهای انجام‌شدنی (todo list) در طول یک ریبیس تعاملی. هش کامیت به‌طور خودکار در ابتدای این قالب قرار خواهد گرفت.

rebase.abbreviateCommands

اگر روی true تنظیم شود، git rebase از نام‌های اختصاری دستورات در فهرست کارهای انجام‌شدنی استفاده خواهد کرد که نتیجه‌ای شبیه به این خواهد داشت: 
p deadbee The oneline of the commit
p fa1afe1 The oneline of the next commit
...

به جای:

pick deadbee The oneline of the commit
pick fa1afe1 The oneline of the next commit
...

پیش‌فرض false است.

rebase.rescheduleFailedExec

دستورات exec شکست‌خورده را به‌طور خودکار دوباره زمان‌بندی می‌کند. این فقط در حالت تعاملی (یا زمانی که گزینه --exec ارائه شده باشد) معنا دارد. این معادل مشخص کردن گزینه --reschedule-failed-exec است.

rebase.forkPoint

اگر روی false تنظیم شود، گزینه --no-fork-point را به‌طور پیش‌فرض تنظیم می‌کند.

rebase.rebaseMerges

آیا و چگونه گزینه --rebase-merges به صورت پیش‌فرض تنظیم شود. می‌تواند rebase-cousins، no-rebase-cousins، یا یک مقدار بولی باشد. تنظیم روی true یا روی no-rebase-cousins معادل --rebase-merges=no-rebase-cousins است، تنظیم روی rebase-cousins معادل --rebase-merges=rebase-cousins است، و تنظیم روی false معادل --no-rebase-merges می‌باشد. ارسال --rebase-merges در خط فرمان، با یا بدون آرگومان، هرگونه پیکربندی rebase.rebaseMerges را بازنویسی می‌کند.

rebase.maxLabelLength

هنگام تولید نام‌های برچسب (label) از موضوعات کامیت، نام‌ها را به این طول کوتاه می‌کند. به‌طور پیش‌فرض، نام‌ها به کمی کمتر از NAME_MAX کوتاه می‌شوند (تا اجازه داده شود برای مثال فایل‌های .lock برای مرجع‌های مجزای متناظر نوشته شوند).

receive.advertiseAtomic

به‌طور پیش‌فرض، git-receive-pack قابلیت پوش اتمیک (atomic push) را به کلاینت‌های خود اعلان خواهد کرد. اگر نمی‌خواهید این قابلیت اعلان شود، این متغیر را روی false تنظیم کنید.

receive.advertisePushOptions

هنگامی که روی true تنظیم شود، git-receive-pack قابلیت گزینه‌های پوش (push options) را به کلاینت‌های خود اعلان می‌کند. به‌طور پیش‌فرض false است.

receive.autogc

به‌طور پیش‌فرض، git-receive-pack پس از دریافت داده‌ها از git-push و به‌روزرسانی مرجع‌ها، دستور "git maintenance run --auto" را اجرا می‌کند. می‌توانید با تنظیم این متغیر روی false، آن را متوقف کنید.

receive.certNonceSeed

با تنظیم این متغیر روی یک رشته، git receive-pack یک git push --signed را می‌پذیرد و آن را با استفاده از یک "nonce" محافظت‌شده توسط HMAC با استفاده از این رشته به عنوان یک کلید مخفی تأیید اعتبار می‌کند.

receive.certNonceSlop

هنگامی که یک git push --signed یک گواهی پوش همراه با یک "nonce" ارسال می‌کند که توسط یک receive-pack ارائه‌دهنده همان مخزن در این تعداد ثانیه صادر شده است، "nonce" یافت‌شده در گواهی را به GIT_PUSH_CERT_NONCE برای قلاب‌ها (hooks) صادر کند (به جای آنچه receive-pack از سمت ارسال‌کننده خواسته بود بگنجاند). این کار ممکن است نوشتن بررسی‌ها در قلاب‌های pre-receive و post-receive را کمی آسان‌تر کند. به جای بررسی متغیر محیطی GIT_PUSH_CERT_NONCE_SLOP که ثبت می‌کند nonce تا چند ثانیه کهنه است تا تصمیم بگیرند آیا می‌خواهند گواهی را بپذیرند یا خیر، آن‌ها تنها می‌توانند بررسی کنند که آیا GIT_PUSH_CERT_NONCE_STATUS روی OK است یا خیر.

receive.fsckObjects

اگر روی true تنظیم شود، git-receive-pack تمام اشیاء دریافتی را بررسی خواهد کرد. برای آنچه بررسی می‌شود، به transfer.fsckObjects مراجعه کنید. مقدار پیش‌فرض false است. در صورت تنظیم نشدن، مقدار transfer.fsckObjects به جای آن استفاده می‌شود.

receive.fsck.<msg-id>

مانند fsck.<msg-id> عمل می‌کند، اما توسط git-receive-pack(1) به جای git-fsck(1) استفاده می‌شود. برای جزئیات به مستندات fsck.<msg-id> مراجعه کنید.

receive.fsck.skipList

مانند fsck.skipList، اما توسط git-receive-pack(1) به جای git-fsck(1) استفاده می‌شود. برای جزئیات به مستندات fsck.skipList مراجعه کنید.

receive.keepAlive

پس از دریافت بسته از کلاینت، receive-pack ممکن است در حین پردازش بسته هیچ خروجی‌ای تولید نکند (اگر --quiet مشخص شده باشد)، که باعث می‌شود برخی شبکه‌ها اتصال TCP را قطع کنند. با تنظیم این گزینه، اگر receive-pack در این مرحله برای مدت receive.keepAlive ثانیه هیچ داده‌ای مخابره نکند، یک بسته کوتاه زنده نگه‌داری (keepalive) ارسال می‌کند. مقدار پیش‌فرض 5 ثانیه است؛ برای غیرفعال کردن کامل زنده نگه‌داری‌ها آن را روی 0 قرار دهید.

receive.unpackLimit

اگر تعداد اشیاء دریافتی در یک پوش کمتر از این محدودیت باشد، اشیاء در قالب فایل‌های اشیاء مجزا (loose objects) بازگشایی می‌شوند. با این حال اگر تعداد اشیاء دریافتی مساوی یا بیشتر از این حد باشد، بسته دریافتی پس از افزودن پایه‌های دلتای مفقود، به صورت یک بسته ذخیره می‌شود. ذخیره بسته حاصل از یک پوش می‌تواند عملیات پوش را سریع‌تر تکمیل کند، به ویژه در سیستم‌های فایل کند. در صورت تنظیم نشدن، مقدار transfer.unpackLimit به جای آن استفاده می‌شود.

receive.maxInputSize

اگر اندازه جریان بسته ورودی بزرگ‌تر از این حد باشد، git-receive-pack به جای پذیرش فایل بسته، با خطا متوقف می‌شود. اگر تنظیم نشود یا روی 0 تنظیم شود، اندازه نامحدود خواهد بود.

receive.denyDeletes

اگر روی true تنظیم شود، git-receive-pack به‌روزرسانی مرجعی را که منجر به حذف آن مرجع می‌شود رد خواهد کرد. از این گزینه برای جلوگیری از حذف مرجع از طریق یک پوش استفاده کنید.

receive.denyDeleteCurrent

اگر روی true تنظیم شود، git-receive-pack به‌روزرسانی مرجعی را که شاخه در حال حاضر وارسی‌شده (checked out) یک مخزن غیرخام (non-bare) را حذف می‌کند، رد خواهد کرد.

receive.denyCurrentBranch

اگر روی true یا "refuse" تنظیم شود، git-receive-pack به‌روزرسانی مرجع به شاخه در حال حاضر وارسی‌شده یک مخزن غیرخام را رد خواهد کرد. چنین پوشی بالقوه خطرناک است زیرا باعث عدم همگام‌سازی HEAD با ایندکس و درخت کاری می‌شود. اگر روی "warn" تنظیم شود، هشداری در مورد چنین پوشی را در stderr چاپ می‌کند اما اجازه می‌دهد پوش ادامه یابد. اگر روی false یا "ignore" تنظیم شود، چنین پوش‌هایی را بدون هیچ پیامی مجاز می‌داند. مقدار پیش‌فرض "refuse" است.

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

به‌طور پیش‌فرض، اگر درخت کاری یا ایندکس تفاوتی با HEAD داشته باشند، "updateInstead" پوش را رد خواهد کرد، اما می‌توان از قلاب push-to-checkout برای سفارشی‌سازی این رفتار استفاده کرد. ببینید: githooks(5).

receive.denyNonFastForwards

اگر روی true تنظیم شود، git-receive-pack به‌روزرسانی مرجعی را که رو به جلو (fast-forward) نیست رد خواهد کرد. از این گزینه برای جلوگیری از چنین به‌روزرسانی‌ای از طریق پوش، حتی اگر آن پوش اجباری باشد (forced push)، استفاده کنید. این متغیر پیکربندی هنگام مقداردهی اولیه یک مخزن اشتراکی تنظیم می‌شود.

receive.hideRefs

این متغیر مشابه transfer.hideRefs است، اما تنها برای receive-pack اعمال می‌شود (و بنابراین بر پوش‌ها تأثیر می‌گذارد، نه واکشی‌ها). تلاش برای به‌روزرسانی یا حذف یک مرجع پنهان توسط git push رد می‌شود.

receive.procReceiveRefs

این یک متغیر چندمقداری است که پیشوندهای مرجع را برای تطابق با دستورات در receive-pack تعریف می‌کند. دستورات منطبق با این پیشوندها توسط یک قلاب خارجی به نام "proc-receive" اجرا خواهند شد، به جای تابع داخلی execute_commands. اگر این متغیر تعریف نشده باشد، قلاب "proc-receive" هرگز استفاده نخواهد شد، و تمام دستورات توسط تابع داخلی execute_commands اجرا خواهند شد.

برای مثال، اگر این متغیر روی "refs/for" تنظیم شود، پوش کردن به مرجعی مانند "refs/for/master" باعث ایجاد یا به‌روزرسانی مرجعی به نام "refs/for/master" نخواهد شد، اما ممکن است با اجرای قلاب "proc-receive" مستقیماً یک درخواست پول (pull request) ایجاد یا به‌روزرسانی کند.

می‌توان اصلاح‌کننده‌های اختیاری را در ابتدای مقدار برای فیلتر کردن دستورات برای اقدامات خاص ارائه داد: ایجاد (a)، تغییر (m)، حذف (d). علامت ! می‌تواند در اصلاح‌کننده‌ها برای نفی مدخل پیشوند مرجع گنجانده شود. برای مثال:

git config --system --add receive.procReceiveRefs ad:refs/heads
git config --system --add receive.procReceiveRefs !:refs/heads

receive.updateServerInfo

اگر روی true تنظیم شود، git-receive-pack پس از دریافت داده‌ها از git-push و به‌روزرسانی مرجع‌ها، git-update-server-info را اجرا می‌کند.

receive.shallowUpdate

اگر روی true تنظیم شود، .git/shallow می‌تواند زمانی که مرجع‌های جدید به ریشه‌های کم‌عمق جدیدی نیاز داشته باشند به‌روزرسانی شود. در غیر این صورت آن مرجع‌ها رد می‌شوند.

reftable.blockSize

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

توان‌هایی از دو که با سیستم حافظه مجازی یا سیستم فایل سازگار هستند (مانند 4kB یا 8kB) توصیه می‌شوند. اندازه‌های بزرگ‌تر (64kB) می‌توانند فشرده‌سازی بهتری را به همراه داشته باشند، همراه با احتمال افزایش هزینه اعمال‌شده بر خوانندگان در حین دسترسی.

بزرگ‌ترین اندازه بلوک 16777215 بایت (15.99 MiB) است. مقدار پیش‌فرض 4096 بایت (4kB) است. مقدار 0 از مقدار پیش‌فرض استفاده خواهد کرد.

reftable.restartInterval

فاصله‌ای که در آن نقاط راه‌اندازی مجدد (restart points) ایجاد می‌شوند. بک‌اند reftable نقاط راه‌اندازی مجدد را هنگام ایجاد فایل تعیین می‌کند. عدد 16 ممکن است برای اندازه‌های بلوک کوچک‌تر (4k یا 8k) و عدد 64 برای اندازه‌های بلوک بزرگ‌تر (64k) مناسب‌تر باشد.

نقاط راه‌اندازی مجدد متوالی‌تر فشرده‌سازی پیشوند را کاهش داده و فضای مصرف‌شده توسط جدول restart را افزایش می‌دهد، که هر دو اندازه فایل را افزایش می‌دهند.

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

حداکثر 65535 نقطه راه‌اندازی مجدد در هر بلوک پشتیبانی می‌شود.

مقدار پیش‌فرض، ایجاد نقاط راه‌اندازی مجدد در هر 16 رکورد است. مقدار 0 از مقدار پیش‌فرض استفاده خواهد کرد.

reftable.indexObjects

آیا بک‌اند reftable باید بلوک‌های اشیاء را بنویسد یا خیر. بلوک‌های اشیاء یک نگاشت معکوس از شناسه شیء (object ID) به مرجع‌هایی هستند که به آن‌ها اشاره می‌کنند.

مقدار پیش‌فرض true است.

reftable.geometricFactor

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

به‌طور پیش‌فرض، دنباله هندسی از ضریب 2 استفاده می‌کند، به این معنی که برای هر جدول، جدول بزرگ‌تر بعدی باید حداقل دو برابر بزرگ‌تر باشد. حداکثر ضریب 256 پشتیبانی می‌شود.

reftable.lockTimeout

هر زمان که بک‌اند reftable یک جدول جدید به پشته اضافه می‌کند، پیش از به‌روزرسانی آن باید فایل مرکزی "tables.list" را قفل کند. این پیکربندی کنترل می‌کند که فرآیند در صورتی که فرآیند دیگری از قبل قفل را در اختیار گرفته باشد، چه مدت برای به دست آوردن قفل منتظر بماند. مقدار 0 به معنای عدم تلاش مجدد است؛ مقدار -1 به معنای تلاش نامحدود است. مقدار پیش‌فرض 100 است (یعنی تلاش مجدد برای 100 میلی‌ثانیه).

remote.pushDefault

ریموت پیش‌فرض برای ارسال (push). این متغیر branch.<name>.remote را برای تمام شاخه‌ها بازنویسی می‌کند، و برای شاخه‌های خاص توسط branch.<name>.pushRemote بازنویسی می‌شود.

remote.<name>.url

نشانی URL یک مخزن ریموت. به git-fetch(1) یا git-push(1) مراجعه کنید. یک ریموت پیکربندی‌شده می‌تواند چندین URL داشته باشد؛ در این حالت اولین نشانی برای واکشی (fetch) و همه آن‌ها برای ارسال (push) استفاده می‌شوند (با فرض اینکه هیچ remote.<name>.pushurl تعریف نشده باشد). تنظیم این کلید روی رشته خالی، فهرست نشانی‌ها را پاک می‌کند و به شما اجازه می‌دهد پیکربندی قبلی را بازنویسی کنید.

remote.<name>.pushurl

نشانی URL ارسال (push) یک مخزن ریموت. به git-push(1) مراجعه کنید. اگر گزینه pushurl در یک ریموت پیکربندی‌شده وجود داشته باشد، به جای remote.<name>.url برای ارسال استفاده می‌شود. یک ریموت پیکربندی‌شده می‌تواند چندین URL ارسال داشته باشد؛ در این حالت ارسال به همه آن‌ها انجام می‌شود. تنظیم این کلید روی رشته خالی، فهرست نشانی‌ها را پاک می‌کند و به شما اجازه می‌دهد پیکربندی قبلی را بازنویسی کنید.

remote.<name>.proxy

برای ریموت‌هایی که به curl نیاز دارند (http، https و ftp)، نشانی پروکسی مورد استفاده برای آن ریموت. برای غیرفعال کردن پروکسی برای آن ریموت، آن را روی رشته خالی تنظیم کنید.

remote.<name>.proxyAuthMethod

برای ریموت‌هایی که به curl نیاز دارند (http، https و ftp)، روش مورد استفاده برای احراز هویت در برابر پروکسی در حال استفاده (که احتمالاً در remote.<name>.proxy تنظیم شده است). به http.proxyAuthMethod مراجعه کنید.

remote.<name>.fetch

مجموعه پیش‌فرض "refspec" برای git-fetch(1). به git-fetch(1) مراجعه کنید.

remote.<name>.push

مجموعه پیش‌فرض "refspec" برای git-push(1). به git-push(1) مراجعه کنید.

remote.<name>.mirror

اگر true باشد، ارسال (push) به این ریموت به‌طور خودکار به‌گونه‌ای عمل می‌کند که گویی گزینه --mirror در خط فرمان داده شده است.

remote.<name>.skipDefaultUpdate

مترادفی منسوخ‌شده برای remote.<name>.skipFetchAll (اگر هر دو در فایل‌های پیکربندی با مقادیر متفاوتی تنظیم شده باشند، مقدار آخرین رخداد استفاده خواهد شد).

remote.<name>.skipFetchAll

اگر true باشد، هنگام به‌روزرسانی با استفاده از git-fetch(1)، زیردستور update از git-remote(1) از این ریموت صرف‌نظر می‌شود، و توسط وظیفه پیش‌واکشی (prefetch) در git maintenance نادیده گرفته خواهد شد.

remote.<name>.receivepack

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

remote.<name>.uploadpack

برنامه پیش‌فرض برای اجرا در سمت ریموت هنگام واکشی (fetch). گزینه --upload-pack در git-fetch-pack(1) را ببینید.

remote.<name>.tagOpt

تنظیم این مقدار روی --no-tags دنبال کردن خودکار برچسب‌ها را هنگام واکشی از ریموت <name> غیرفعال می‌کند. تنظیم آن روی --tags تمام برچسب‌ها را از ریموت <name> واکشی خواهد کرد، حتی اگر از نوک شاخه‌های ریموت قابل دسترسی نباشند. ارسال مستقیم این فلگ‌ها به git-fetch(1) می‌تواند این تنظیم را بازنویسی کند. گزینه‌های --tags و --no-tags در git-fetch(1) را ببینید.

remote.<name>.vcs

تنظیم این متغیر روی مقدار <vcs> باعث می‌شود Git با استفاده از برنامه کمکی git-remote-<vcs> با ریموت تعامل کند.

remote.<name>.prune

هنگامی که روی true تنظیم شود، واکشی از این ریموت به‌طور پیش‌فرض تمام مراجع ردیابی ریموت را که دیگر روی ریموت وجود ندارند نیز حذف می‌کند (گویی گزینه --prune در خط فرمان داده شده است). تنظیمات fetch.prune را در صورت وجود، بازنویسی می‌کند.

remote.<name>.pruneTags

هنگامی که روی true تنظیم شود، واکشی از این ریموت به‌طور پیش‌فرض تمام برچسب‌های محلی را که دیگر روی ریموت وجود ندارند نیز حذف می‌کند، در صورتی که هرس کردن (pruning) به‌طور کلی از طریق remote.<name>.prune، fetch.prune یا --prune فعال شده باشد. تنظیمات fetch.pruneTags را در صورت وجود، بازنویسی می‌کند.

همچنین به remote.<name>.prune و بخش PRUNING در git-fetch(1) مراجعه کنید.

remote.<name>.promisor

هنگامی که روی true تنظیم شود، از این ریموت برای واکشی اشیاء promisor استفاده خواهد شد.

remote.<name>.partialclonefilter

فیلتری که هنگام واکشی از این ریموت promisor اعمال خواهد شد. تغییر دادن یا پاک کردن این مقدار فقط روی واکشی‌ها برای کامیت‌های جدید تأثیر می‌گذارد. برای واکشی اشیاء مرتبط با کامیت‌هایی که هم‌اکنون در پایگاه‌داده محلی اشیاء وجود دارند، از گزینه --refetch در git-fetch(1) استفاده کنید.

remote.<name>.serverOption

مجموعه پیش‌فرض گزینه‌های سرور که هنگام واکشی از این ریموت استفاده می‌شوند. این گزینه‌های سرور می‌توانند توسط آرگومان‌های خط فرمان --server-option= بازنویسی شوند.

این یک متغیر چندمقداری است، و می‌توان از یک مقدار خالی در فایل پیکربندی با اولویت بالاتر (مثلاً .git/config در یک مخزن) برای پاک کردن مقادیر به ارث برده شده از فایل‌های پیکربندی با اولویت پایین‌تر (مثلاً $HOME/.gitconfig) استفاده کرد.

remote.<name>.negotiationRestrict

هنگام مذاکره با این ریموت در زمان git fetch، کامیت‌های اعلام‌شده به عنوان خطوط "have" را تنها به مواردی محدود می‌کند که از مراجع منطبق با الگوهای ارائه‌شده قابل دسترسی باشند. این گزینه پیکربندی چندمقداری مانند --negotiation-restrict در خط فرمان رفتار می‌کند.

هر مقدار یا یک نام دقیق مرجع است (مثلاً refs/heads/release) یا یک الگوی گلوب (glob) (مثلاً refs/heads/release/*). نحو الگو همانند --negotiation-restrict است.

این مقادیر پیکربندی به عنوان پیش‌فرض‌ها برای گزینه خط فرمان --negotiation-restrict استفاده می‌شوند. اگر --negotiation-restrict (یا مترادف آن --negotiation-tip) در خط فرمان مشخص شده باشد، از مقادیر پیکربندی استفاده نمی‌شود.

این مقادیر همچنین بر مذاکره در زمان git push تأثیر می‌گذارند در صورتی که push.negotiate فعال باشد.

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

remote.<name>.negotiationInclude

هنگام مذاکره با این ریموت در زمان git fetch، کلاینت فهرستی از کامیت‌هایی را که به صورت محلی وجود دارند اعلام می‌کند. در مخازنی با مراجع زیاد، این فهرست "haves" ممکن است کوتاه (truncate) شود. بسته به ساختار داده‌ها، نادیده گرفتن برخی مراجع ممکن است پرهزینه باشد. این گزینه پیکربندی چندمقداری، مراجع، هش‌های کامیت، یا الگوهای گلوب مرجعی را مشخص می‌کند که نوک آن‌ها باید همیشه در طول مذاکره واکشی با این ریموت به عنوان کامیت‌های "have" ارسال شود.

هر مقدار یا یک نام دقیق مرجع (مثلاً refs/heads/release)، یک هش کامیت، یا یک الگوی گلوب (مثلاً refs/heads/release/*) است. نحو الگو همانند --negotiation-include است.

این مقادیر پیکربندی به عنوان پیش‌فرض‌ها برای گزینه خط فرمان --negotiation-include استفاده می‌شوند. اگر --negotiation-include در خط فرمان مشخص شده باشد، از مقادیر پیکربندی استفاده نمی‌شود.

این گزینه به فرایند معمول مذاکره افزوده می‌شود: الگوریتم مذاکره همچنان اجرا می‌شود و کامیت‌های منتخب خود را اعلام می‌کند، اما مراجع منطبق بر remote.<name>.negotiationInclude به صورت بدون قید و شرط علاوه بر کامیت‌های انتخاب‌شده از روی هیوریستیک ارسال می‌شوند.

این مقادیر همچنین بر مذاکره در زمان git push تأثیر می‌گذارند در صورتی که push.negotiate فعال باشد.

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

remote.<name>.followRemoteHEAD

نحوه برخورد git-fetch(1) با به‌روزرسانی‌های remotes/<name>/HEAD هنگام واکشی با استفاده از refspecهای پیکربندی‌شده یک ریموت. مقدار پیش‌فرض "create" است که در صورتی که remotes/<name>/HEAD روی ریموت وجود داشته باشد اما محلی نباشد، آن را ایجاد می‌کند؛ این عمل به مرجع محلی از قبل موجود دست نمی‌زند. تنظیم آن روی "warn" در صورتی که ریموت مقداری متفاوت از مقدار محلی داشته باشد پیامی چاپ می‌کند؛ در صورتی که هیچ مرجع محلی وجود نداشته باشد، مانند "create" رفتار می‌کند. حالتی از "warn" مقدار "warn-if-not-$branch" است که مانند "warn" رفتار می‌کند، اما اگر HEAD روی ریموت برابر با $branch باشد، پیامی نمایش نمی‌دهد. تنظیم آن روی "always" مرجع remotes/<name>/HEAD را بی‌صدا به مقدار موجود روی ریموت به‌روزرسانی می‌کند. در نهایت، تنظیم آن روی "never" هرگز مرجع محلی را تغییر نداده یا ایجاد نمی‌کند.

remotes.<group>

فهرست ریموت‌هایی که توسط "git remote update <group>" واکشی می‌شوند. به git-remote(1) مراجعه کنید.

repack.useDeltaBaseOffset

به‌طور پیش‌فرض، git-repack(1) بسته‌هایی ایجاد می‌کند که از delta-base offset استفاده می‌کنند. اگر نیاز دارید مخزن خود را با گیت قدیمی‌تر از نسخه 1.4.4 به اشتراک بگذارید، چه به صورت مستقیم یا از طریق یک پروتکل غیرهوشمند مانند http، باید این گزینه را روی "false" تنظیم کرده و مجدداً بسته‌بندی کنید. دسترسی از نسخه‌های قدیمی گیت روی پروتکل بومی تحت تأثیر این گزینه قرار نمی‌گیرد.

repack.packKeptObjects

اگر روی true تنظیم شود، باعث می‌شود git repack به‌گونه‌ای عمل کند که گویی --pack-kept-objects ارسال شده است. برای جزئیات به git-repack(1) مراجعه کنید. در حالت عادی پیش‌فرض false است، اما اگر یک نمایه بیت‌مپ در حال نوشته شدن باشد (چه از طریق --write-bitmap-index یا repack.writeBitmaps)، پیش‌فرض true خواهد بود.

repack.useDeltaIslands

اگر روی true تنظیم شود، باعث می‌شود git repack به‌گونه‌ای عمل کند که گویی --delta-islands ارسال شده است. مقدار پیش‌فرض false است.

repack.writeBitmaps

هنگامی که true باشد، گیت هنگام بسته‌بندی تمام اشیاء روی دیسک (مثلاً زمانی که git repack -a اجرا می‌شود)، یک نمایه بیت‌مپ می‌نویسد. این نمایه می‌تواند مرحله "شمارش اشیاء" در بسته‌های بعدی ایجادشده برای cloneها و fetchها را سرعت بخشد، به بهای مقداری فضای دیسک و زمان اضافی صرف‌شده در بسته‌بندی مجدد اولیه. اگر چندین packfile ایجاد شوند، این گزینه هیچ اثری ندارد. در مخازن bare پیش‌فرض true و در غیر این صورت false است.

repack.updateServerInfo

اگر روی false تنظیم شود، git-repack(1) دستور git-update-server-info(1) را اجرا نخواهد کرد. مقدار پیش‌فرض true است. در صورت true بودن، می‌تواند توسط گزینه -n در git-repack(1) بازنویسی شود.

repack.cruftWindow, repack.cruftWindowMemory, repack.cruftDepth, repack.cruftThreads

پارامترهای مورد استفاده توسط git-pack-objects(1) هنگام تولید یک بسته زائدات (cruft pack) در صورتی که پارامترهای مربوطه در خط فرمان داده نشده باشند. برای مقادیر پیش‌فرض و معانی آن‌ها، به متغیرهای پیکربندی با نام مشابه pack.* مراجعه کنید.

repack.midxMustContainCruft

هنگامی که روی true تنظیم شود، git-repack(1) هنگامی که با --write-midx فراخوانی می‌شود، بسته‌(های) cruft را در صورت وجود بدون قید و شرط در نمایه چندبسته‌ای (MIDX) می‌گنجاند. هنگامی که false باشد، بسته‌های cruft تنها در صورت لزوم در MIDX گنجانده می‌شوند (مثلاً به این دلیل که ممکن است برای تشکیل یک بستار دسترسی‌پذیری با بیت‌مپ‌های MIDX مورد نیاز باشند). مقدار پیش‌فرض true است.

repack.midxSplitFactor

ضریب مورد استفاده در شرط ادغام هندسی هنگام فشرده‌سازی لایه‌های افزایشی MIDX در حین اجرای git repack زمانی که با گزینه --write-midx=incremental فراخوانی می‌شود.

لایه‌های مجاور زمانی ادغام می‌شوند که تعداد اشیاء انباشته‌شده لایه جدیدتر از 1/<N> تعداد اشیاء لایه عمیق‌تر بعدی فراتر رود. باید حداقل 2 باشد. مقدار پیش‌فرض 2 است.

repack.midxNewLayerThreshold

حداقل تعداد بسته‌ها در لایه رأس MIDX پیش از آنکه آن بسته‌ها به عنوان نامزد برای بسته‌بندی مجدد هندسی در طول git repack --write-midx=incremental در نظر گرفته شوند.

هنگامی که لایه رأس بسته‌های کمتری از این آستانه داشته باشد، آن بسته‌ها به‌طور کامل از بسته‌بندی مجدد هندسی کنار گذاشته شده و بنابراین دست‌نخورده باقی می‌مانند. باید حداقل 1 باشد. مقدار پیش‌فرض 8 است.

rerere.autoUpdate

هنگامی که روی true تنظیم شود، git-rerere پس از حل تمیز تعارض‌ها با استفاده از راه‌حل‌های از پیش ثبت‌شده، ایندکس را با محتویات حاصل به‌روزرسانی می‌کند. مقدار پیش‌فرض false است.

rerere.enabled

فعال‌سازی ثبت تعارض‌های حل‌شده، تا در صورت مواجهه مجدد با قطعات تعارض (conflict hunks) یکسان، بتوان آن‌ها را به‌طور خودکار حل کرد. به‌طور پیش‌فرض، git-rerere(1) در صورتی که پوشه rr-cache در زیر $GIT_DIR وجود داشته باشد فعال است، مثلاً اگر قبلاً از "rerere" در مخزن استفاده شده باشد.

revert.reference

تنظیم این متغیر روی true باعث می‌شود git revert به‌گونه‌ای رفتار کند که گویی گزینه --reference داده شده است.

safe.bareRepository

مشخص می‌کند که گیت با کدام مخازن bare کار خواهد کرد. مقادیری که در حال حاضر پشتیبانی می‌شوند عبارتند از:
•all: گیت با تمام مخازن bare کار می‌کند. این مقدار در Git 2.x پیش‌فرض است.
•explicit: گیت فقط با مخازن bare کار می‌کند که از طریق گزینه سطح بالای خط فرمان --git-dir یا متغیر محیطی GIT_DIR مشخص شده‌اند (به git(1) مراجعه کنید). این مقدار در Git 3.0 پیش‌فرض خواهد بود.

اگر در گردش کار خود از مخازن bare استفاده نمی‌کنید، ممکن است مفید باشد که safe.bareRepository را در پیکربندی سراسری (global) خود روی explicit تنظیم کنید. این کار شما را در برابر حملاتی که شامل کلون کردن مخزنی حاوی یک مخزن bare و اجرای یک دستور Git در آن پوشه است، محافظت می‌کند.

اگر به‌طور منظم از مخازن bare استفاده می‌کنید و می‌خواهید رفتار فعلی را پس از ارتقا به Git 3.0 حفظ کنید، safe.bareRepository را در پیکربندی سراسری یا سیستمی خود روی all تنظیم کنید.

این تنظیم پیکربندی فقط در پیکربندی محافظت‌شده رعایت می‌شود (به بخش موسوم به “SCOPES” مراجعه کنید). این امر مانع از دستکاری این مقدار توسط مخازن غیرقابل اعتماد می‌شود.

safe.directory

این مدخل‌های پیکربندی، پوشه‌های تحت ردیابی گیت را مشخص می‌کنند که حتی در صورت تعلق به شخصی غیر از کاربر فعلی، امن در نظر گرفته می‌شوند. به‌طور پیش‌فرض، گیت حتی از تجزیه (parse) پیکربندی گیت مخزنی که متعلق به شخص دیگری است امتناع می‌کند، چه رسد به اجرای قلاب‌های (hooks) آن، و این تنظیم پیکربندی به کاربران اجازه می‌دهد استثناها را مشخص کنند، مثلاً برای مخازنی که عمداً به اشتراک گذاشته شده‌اند (گزینه --shared در git-init(1) را ببینید).

این یک تنظیم چندمقداری است، یعنی می‌توانید بیش از یک پوشه را از طریق git config --add اضافه کنید. برای بازنشانی فهرست پوشه‌های امن (مثلاً برای بازنویسی هر پوشه‌ای از این دست که در پیکربندی سیستم مشخص شده است)، یک مدخل safe.directory با مقدار خالی اضافه کنید.

این تنظیم پیکربندی فقط در پیکربندی محافظت‌شده رعایت می‌شود (به بخش موسوم به “SCOPES” مراجعه کنید). این امر مانع از دستکاری این مقدار توسط مخازن غیرقابل اعتماد می‌شود.

مقدار این تنظیم درون‌یابی (interpolate) می‌شود، یعنی ~/<path> به یک مسیر نسبی نسبت به پوشه خانگی (home) گسترش می‌یابد و %(prefix)/<path> به یک مسیر نسبی نسبت به پیشوند (زمان اجرا) گیت گسترش می‌یابد.

برای انصراف کامل از این بررسی امنیتی، safe.directory را روی رشته * تنظیم کنید. این کار اجازه می‌دهد با تمام مخازن به‌گونه‌ای رفتار شود که گویی پوشه آن‌ها در فهرست safe.directory آمده است. اگر safe.directory=* در پیکربندی سیستم تنظیم شده باشد و بخواهید این محافظت را مجدداً فعال کنید، فهرست خود را با یک مقدار خالی پیش از برشمردن مخازنی که امن می‌دانید مقداردهی اولیه کنید. ارائه یک پوشه که /* به انتهای آن افزوده شده است، اجازه دسترسی به تمام مخازن زیر آن پوشه مشخص‌شده را می‌دهد.

همان‌طور که توضیح داده شد، گیت به‌طور پیش‌فرض تنها به شما اجازه می‌دهد به مخازنی دسترسی داشته باشید که متعلق به خودتان هستند، یعنی کاربری که گیت را اجرا می‌کند. با این حال، هنگامی که گیت به عنوان root در یک پلتفرم غیر ویندوزی که sudo را ارائه می‌دهد اجرا می‌شود، متغیر محیطی SUDO_UID را که sudo ایجاد می‌کند بررسی کرده و علاوه بر شناسه root، دسترسی به uid ثبت‌شده به عنوان مقدار آن را نیز مجاز می‌داند. این امر برای تسهیل انجام توالی معمول "make && sudo make install" در طول نصب است. یک فرآیند گیت که تحت sudo اجرا می‌شود، در قالب root کار می‌کند اما دستور sudo متغیر محیطی را صادر (export) می‌کند تا ثبت کند کاربر اصلی چه شناسه‌ای داشته است. اگر این مورد نظر شما نیست و می‌خواهید گیت در عوض فقط به مخازنی که متعلق به root هستند اعتماد کند، می‌توانید متغیر SUDO_UID را پیش از فراخوانی گیت از محیط root حذف کنید.

sendemail.identity

یک هویت (identity) پیکربندی. هنگامی که ارائه شود، باعث می‌شود مقادیر موجود در زیربخش sendemail.<identity> بر مقادیر موجود در بخش sendemail اولویت پیدا کنند. هویت پیش‌فرض مقدار sendemail.identity است.

sendemail.smtpEncryption

برای توضیحات به git-send-email(1) مراجعه کنید. توجه داشته باشید که این تنظیم مشمول سازوکار identity نیست.

sendemail.smtpSSLCertPath

مسیر ca-certificates (یا یک پوشه یا یک فایل تکی). برای غیرفعال کردن اعتبارسنجی گواهی، آن را روی یک رشته خالی تنظیم کنید.

sendemail.smtpSSLClientCert

مسیر فایل گواهی کلاینت که در صورت درخواست سرور ارائه می‌شود. این گزینه زمانی که سرور برای اعتبارسنجی گواهی‌های کلاینت پیکربندی شده باشد الزامی است. اگر کلید خصوصی مربوطه در فایل گنجانده نشده باشد، باید با استفاده از sendemail.smtpSSLClientKey یا گزینه --smtp-ssl-client-key فراهم شود.

sendemail.smtpSSLClientKey

مسیر فایل کلید خصوصی کلاینت که با گواهی کلاینت مطابقت دارد. برای اجتناب از پیکربندی نادرست، این پیکربندی باید همراه با sendemail.smtpSSLClientCert یا گزینه --smtp-ssl-client-cert استفاده شود. اگر کلید کلاینت در گواهی کلاینت گنجانده شده باشد، انتخاب کلید خصوصی به فرمت گواهی بستگی دارد. برای جزئیات بیشتر به https://metacpan.org/pod/IO::Socket::SSL مراجعه کنید.

sendemail.<identity>.*

نسخه‌های مختص هویت از پارامترهای sendemail.* که در زیر آمده‌اند، که در صورت انتخاب این هویت چه از طریق خط فرمان یا sendemail.identity، بر آن‌ها اولویت دارند.

sendemail.multiEdit

اگر true باشد (پیش‌فرض)، یک نمونه ویرایشگر تکی برای ویرایش فایل‌هایی که باید ویرایش کنید اجرا خواهد شد (وصله‌ها زمانی که --annotate استفاده شود، و خلاصه زمانی که --compose استفاده شود). اگر false باشد، فایل‌ها یکی پس از دیگری ویرایش می‌شوند و هر بار یک ویرایشگر جدید اجرا می‌شود.

sendemail.confirm

پیش‌فرض برای تأیید گرفتن پیش از ارسال را تنظیم می‌کند. باید یکی از موارد always، never، cc، compose یا auto باشد. برای مفهوم این مقادیر، به --confirm در مستندات git-send-email(1) مراجعه کنید.

sendemail.mailmap

اگر true باشد، باعث می‌شود git-send-email(1) فرض را بر --mailmap بگذارد، در غیر این صورت --no-mailmap فرض می‌شود. به‌طور پیش‌فرض False است.

sendemail.mailmap.file

مکان یک فایل افزایشی mailmap مختص git-send-email(1). ابتدا mailmap پیش‌فرض و mailmap.file بارگذاری می‌شوند. بنابراین، مدخل‌های موجود در این فایل بر مدخل‌های مکان‌های پیش‌فرض mailmap اولویت دارند. به gitmailmap(5) مراجعه کنید.

sendemail.mailmap.blob

مشابه sendemail.mailmap.file، اما مقدار را به عنوان یک مرجع به یک blob در مخزن در نظر می‌گیرد. مدخل‌های موجود در sendemail.mailmap.file بر مدخل‌های اینجا اولویت دارند. به gitmailmap(5) مراجعه کنید.

sendemail.aliasesFile

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

sendemail.aliasFileType

قالب فایل(های) مشخص‌شده در sendemail.aliasesFile. باید یکی از موارد mutt، mailrc، pine، elm، gnus یا sendmail باشد.

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

sendmail

•نام‌های مستعار نقل‌قول‌شده و نشانی‌های نقل‌قول‌شده پشتیبانی نمی‌شوند: خطوط حاوی نماد " نادیده گرفته می‌شوند.
•تغییر مسیر به یک فایل (/path/name) یا لوله (|command) پشتیبانی نمی‌شود.
•شامل کردن فایل (:include: /path/name) پشتیبانی نمی‌شود.
•برای هرگونه ساختار صریحاً پشتیبانی‌نشده و هر خط دیگری که توسط تجزیه‌کننده شناخته نشود، هشدارهایی در خروجی خطای استاندارد چاپ می‌شوند.

sendemail.annotate, sendemail.bcc, sendemail.cc, sendemail.ccCmd, sendemail.chainReplyTo, sendemail.envelopeSender, sendemail.from, sendemail.headerCmd, sendemail.signedOffByCc, sendemail.smtpPass, sendemail.suppressCc, sendemail.suppressFrom, sendemail.to, sendemail.toCmd, sendemail.smtpDomain, sendemail.smtpServer, sendemail.smtpServerPort, sendemail.smtpServerOption, sendemail.smtpUser, sendemail.imapSentFolder, sendemail.useImapOnly, sendemail.thread, sendemail.transferEncoding, sendemail.validate, sendemail.xmailer

این متغیرهای پیکربندی همگی مقداری پیش‌فرض برای گزینه‌های خط فرمان git-send-email(1) ارائه می‌دهند. برای جزئیات به مستندات آن مراجعه کنید.

sendemail.outlookidfix

اگر true باشد، باعث می‌شود git-send-email(1) گزینه --outlook-id-fix را فرض کند، و اگر false باشد فرض را بر --no-outlook-id-fix می‌گذارد. در صورت مشخص نشدن، به همان شیوه‌ای عمل می‌کند که گویی --outlook-id-fix مشخص نشده است.

sendemail.signedOffCc (منسوخ‌شده)

نام مستعار منسوخ‌شده برای sendemail.signedOffByCc.

sendemail.smtpBatchSize

تعداد پیام‌هایی که در هر اتصال ارسال می‌شوند، که پس از آن ورود مجدد رخ خواهد داد. اگر مقدار 0 یا تعریف‌نشده باشد، تمام پیام‌ها در یک اتصال ارسال می‌شوند. همچنین گزینه --batch-size در git-send-email(1) را ببینید.

sendemail.smtpReloginDelay

تعداد ثانیه‌های انتظار پیش از اتصال مجدد به سرور smtp. همچنین گزینه --relogin-delay در git-send-email(1) را ببینید.

sendemail.forbidSendmailVariables

برای اجتناب از خطاهای رایج پیکربندی نادرست، git-send-email(1) در صورت وجود هرگونه گزینه پیکربندی برای sendmail همراه با یک هشدار متوقف خواهد شد. این متغیر را برای دور زدن این بررسی تنظیم کنید.

sequence.editor

ویرایشگر متنی مورد استفاده توسط git rebase -i برای ویرایش فایل دستورالعمل بازپایه‌ریزی. این مقدار قرار است هنگام استفاده توسط پوسته (shell) تفسیر شود. می‌تواند توسط متغیر محیطی GIT_SEQUENCE_EDITOR بازنویسی شود. در صورت پیکربندی نشدن، ویرایشگر پیش‌فرض پیام کامیت به جای آن استفاده می‌شود.

showBranch.default

مجموعه پیش‌فرض شاخه‌ها برای git-show-branch(1). به git-show-branch(1) مراجعه کنید.

sideband.allowControlCharacters

به‌طور پیش‌فرض، نویسه‌های کنترلی که از طریق sideband تحویل داده می‌شوند، به استثنای توالی‌های رنگی ANSI ماسک (پوشانده) می‌شوند. این کار از ارسال توالی‌های فرار بالقوه ناخواسته ANSI به ترمینال جلوگیری می‌کند. از این تنظیم پیکربندی برای بازنویسی این رفتار استفاده کنید (مقدار می‌تواند فهرستی جداشده با کاما از کلیدواژه‌های زیر باشد):

color

توالی‌های رنگی ANSI، خطوط جدید (line feeds) و تب‌های افقی مجاز باشند، اما سایر نویسه‌های کنترلی ماسک شوند. این مقدار پیش‌فرض است.

cursor

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

erase

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

false

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

true

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

sideband.<url>.*

اعمال گزینه sideband.* به صورت انتخابی روی نشانی‌های اینترنتی (URLs) خاص. همان منطق تطبیق URL مانند تنظیمات http.<url>.* اعمال می‌شود.

sparse.expectFilesOutsideOfPatterns

معمولاً در دریافت‌های پراکنده (sparse checkouts)، فایل‌هایی که با هیچ الگوی پراکندگی مطابقت ندارند با یک بیت SKIP_WORKTREE در ایندکس علامت‌گذاری شده و در درخت کاری وجود ندارند. بر این اساس، گیت معمولاً بررسی می‌کند که آیا فایل‌های دارای بیت SKIP_WORKTREE بر خلاف انتظار در درخت کاری وجود دارند یا خیر. اگر گیت موردی پیدا کند، آن مسیرها را با پاک کردن بیت‌های مربوطه SKIP_WORKTREE به عنوان موجود علامت‌گذاری می‌کند. این گزینه می‌تواند استفاده شود تا به گیت اعلام کند چنین فایل‌های موجود با وجود رد شدن (present-despite-skipped) مورد انتظار هستند و بررسی برای آن‌ها متوقف شود.

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

اگر در ساختاری هستید که یک عامل خارجی مسئولیت حفظ سازگاری میان حضور فایل‌های درخت کاری و الگوهای پراکندگی را از دوش گیت برمی‌دارد، این را روی true تنظیم کنید. به عنوان مثال، اگر یک سیستم فایل مجازی آگاه از گیت دارید که سازوکار قدرتمندی برای به‌روز نگه داشتن درخت کاری و الگوهای پراکندگی بر اساس الگوهای دسترسی دارد.

صرف‌نظر از این تنظیم، گیت فایل‌های موجود با وجود رد شدن را بررسی نمی‌کند مگر اینکه sparse checkout فعال باشد، بنابراین این گزینه پیکربندی هیچ اثری ندارد مگر اینکه core.sparseCheckout برابر با true باشد.

splitIndex.maxPercentChange

هنگامی که قابلیت ایندکس تفکیک‌شده (split index) استفاده می‌شود، این متغیر درصد ورودی‌هایی را که ایندکس تفکیک‌شده می‌تواند در مقایسه با تعداد کل ورودی‌ها در هر دو ایندکس تفکیک‌شده و ایندکس مشترک (shared index) پیش از نوشته شدن یک ایندکس مشترک جدید داشته باشد، مشخص می‌کند. مقدار باید بین 0 و 100 باشد. اگر مقدار 0 باشد، همیشه یک ایندکس مشترک جدید نوشته می‌شود؛ اگر 100 باشد، هرگز یک ایندکس مشترک جدید نوشته نمی‌شود. به‌طور پیش‌فرض، مقدار 20 است، بنابراین اگر تعداد مدخل‌ها در ایندکس تفکیک‌شده بیش از 20 درصد کل تعداد مدخل‌ها باشد، یک ایندکس مشترک جدید نوشته می‌شود. به git-update-index(1) مراجعه کنید.

splitIndex.sharedIndexExpire

هنگامی که قابلیت ایندکس تفکیک‌شده (split index) استفاده می‌شود، فایل‌های ایندکس مشترکی که از زمان مشخص‌شده توسط این متغیر تغییر نیافته‌اند، هنگام ایجاد یک فایل ایندکس مشترک جدید حذف خواهند شد. مقدار "now" تمام مدخل‌ها را بلافاصله منقضی می‌کند و "never" انقضا را به‌طور کامل متوقف می‌سازد. مقدار پیش‌فرض "2.weeks.ago" است. توجه داشته باشید که یک فایل ایندکس مشترک هر بار که یک فایل split-index جدید بر اساس آن ایجاد شده یا از آن خوانده شود (به منظور انقضا) تغییریافته در نظر گرفته می‌شود. به git-update-index(1) مراجعه کنید.

ssh.variant

به‌طور پیش‌فرض، گیت آرگومان‌های خط فرمان مورد استفاده را بر اساس نام پایه (basename) دستور SSH پیکربندی‌شده (پیکربندی‌شده با استفاده از متغیر محیطی GIT_SSH یا GIT_SSH_COMMAND یا تنظیم پیکربندی core.sshCommand) تعیین می‌کند. اگر نام پایه ناشناخته باشد، گیت با فراخوانی دستور SSH پیکربندی‌شده ابتدا با گزینه -G (چاپ پیکربندی) تلاش می‌کند پشتیبانی از گزینه‌های OpenSSH را تشخیص دهد و سپس از گزینه‌های OpenSSH (در صورت موفقیت‌آمیز بودن) یا بدون هیچ گزینه‌ای به جز میزبان و دستور ریموت (در صورت شکست) استفاده خواهد کرد.

متغیر پیکربندی ssh.variant می‌تواند برای بازنویسی این تشخیص تنظیم شود. مقادیر معتبر عبارتند از: ssh (برای استفاده از گزینه‌های OpenSSH)، plink، putty، tortoiseplink، simple (بدون هیچ گزینه‌ای به جز میزبان و دستور ریموت). تشخیص خودکار پیش‌فرض را می‌توان صریحاً با استفاده از مقدار auto درخواست کرد. هر مقدار دیگری به عنوان ssh در نظر گرفته می‌شود. این تنظیم می‌تواند از طریق متغیر محیطی GIT_SSH_VARIANT نیز بازنویسی شود.

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

•ssh - [-p port] [-4] [-6] [-o option] [username@]host command
•simple - [username@]host command
•plink یا putty - [-P port] [-4] [-6] [username@]host command
•tortoiseplink - [-P port] [-4] [-6] -batch [username@]host command

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

stash.index

اگر این متغیر روی true تنظیم شود، git stash apply و git stash pop به‌گونه‌ای رفتار خواهند کرد که گویی --index داده شده است. مقدار پیش‌فرض false است. به توضیحات موجود در git-stash(1) مراجعه کنید.

این امر همچنین بر فراخوانی‌های git-stash(1) از طریق --autostash از دستوراتی مانند git-merge(1)، git-rebase(1) و git-pull(1) تأثیر می‌گذارد.

stash.showIncludeUntracked

اگر این متغیر روی true تنظیم شود، دستور git stash show فایل‌های ردیابی‌نشده مربوط به یک مدخل ذخیره‌گاه (stash entry) را نشان خواهد داد. مقدار پیش‌فرض false است. به توضیحات دستور 'show' در git-stash(1) مراجعه کنید.

stash.showPatch

اگر این متغیر روی true تنظیم شود، دستور git stash show بدون هیچ گزینه‌ای مدخل ذخیره‌گاه را در قالب وصله نشان می‌دهد. مقدار پیش‌فرض false است. به توضیحات دستور 'show' در git-stash(1) مراجعه کنید.

stash.showStat

اگر این متغیر روی true تنظیم شود، دستور git stash show بدون هیچ گزینه‌ای یک diffstat از مدخل ذخیره‌گاه را نشان می‌دهد. مقدار پیش‌فرض true است. به توضیحات دستور 'show' در git-stash(1) مراجعه کنید.

status.relativePaths

به‌طور پیش‌فرض، git-status(1) مسیرها را نسبی به پوشه جاری نشان می‌دهد. تنظیم این متغیر روی false مسیرها را نسبی به ریشه مخزن نشان می‌دهد (این رفتار پیش‌فرض گیت پیش از نسخه 1.5.4 بود).

status.short

روی true تنظیم کنید تا --short به‌طور پیش‌فرض در git-status(1) فعال شود. گزینه --no-short بر این متغیر اولویت دارد.

status.branch

روی true تنظیم کنید تا --branch به‌طور پیش‌فرض در git-status(1) فعال شود. گزینه --no-branch بر این متغیر اولویت دارد.

status.aheadBehind

روی true تنظیم کنید تا --ahead-behind و روی false تنظیم کنید تا --no-ahead-behind به‌طور پیش‌فرض در git-status(1) برای قالب‌های وضعیت غیر پرسلین فعال شوند. مقدار پیش‌فرض true است.

status.compareBranches

فهرستی جداشده با فاصله از مشخص‌کننده‌های مقایسه شاخه برای استفاده در git-status(1). در حال حاضر تنها @{upstream} و @{push} پشتیبانی می‌شوند. آن‌ها به صورت branch@{upstream} و branch@{push} برای شاخه جاری تفسیر می‌شوند.

در صورت تنظیم نشدن، رفتار پیش‌فرض معادل @{upstream} است، که در برابر شاخه ردیابی بالادست (upstream) پیکربندی‌شده مقایسه می‌کند.

مدخل‌ها به ترتیبی که در پیکربندی ظاهر می‌شوند نمایش داده می‌شوند. مدخل‌های تکراری که به همان مرجع حل‌وفصل می‌شوند پس از اولین رخداد حذف می‌شوند، بنابراین @{push} @{upstream} @{push} حداکثر دو مقایسه را نشان می‌دهد. زمانی که @{upstream} و @{push} به همان شاخه ردیابی ریموت منتهی شوند، تنها یک مقایسه نشان داده می‌شود.

مثال:

[status]
        compareBranches = @{upstream} @{push}

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

status.displayCommentPrefix

اگر روی true تنظیم شود، git-status(1) پیشوند یادداشت را پیش از هر خط خروجی درج می‌کند (شروع با core.commentChar، یعنی به‌طور پیش‌فرض #). این رفتار git-status(1) در Git 1.8.4 و نسخه‌های پیشین بود. مقدار پیش‌فرض false است.

status.renameLimit

تعداد فایل‌هایی که هنگام انجام تشخیص تغییر نام در git-status(1) و git-commit(1) در نظر گرفته می‌شوند. مقدار پیش‌فرض برابر با مقدار diff.renameLimit است.

status.renames

اینکه آیا و چگونه گیت تغییر نام‌ها را در git-status(1) و git-commit(1) تشخیص دهد. اگر روی "false" تنظیم شود، تشخیص تغییر نام غیرفعال می‌شود. اگر روی "true" تنظیم شود، تشخیص پایه تغییر نام فعال می‌گردد. اگر روی "copies" یا "copy" تنظیم شود، گیت کپی‌ها را نیز تشخیص خواهد داد. مقدار پیش‌فرض برابر با مقدار diff.renames است.

status.showStash

اگر روی true تنظیم شود، git-status(1) تعداد مدخل‌های ذخیره‌شده فعلی را نمایش می‌دهد. مقدار پیش‌فرض false است.

status.showUntrackedFiles

به‌طور پیش‌فرض، git-status(1) و git-commit(1) فایل‌هایی را که در حال حاضر توسط گیت ردیابی نمی‌شوند نشان می‌دهند. پوشه‌هایی که تنها حاوی فایل‌های ردیابی‌نشده هستند، تنها با نام پوشه نمایش داده می‌شوند. نمایش فایل‌های ردیابی‌نشده به این معنی است که گیت باید تابع lstat() را روی تمام فایل‌ها در کل مخزن فراخوانی کند، که ممکن است در برخی سیستم‌ها کند باشد. بنابراین، این متغیر نحوه نمایش فایل‌های ردیابی‌نشده توسط دستورات را کنترل می‌کند. مقادیر ممکن عبارتند از:
•no - هیچ فایل ردیابی‌نشده‌ای را نشان ندهد.
•normal - فایل‌ها و پوشه‌های ردیابی‌نشده را نشان دهد.
•all - همچنین فایل‌های تکی درون پوشه‌های ردیابی‌نشده را نشان دهد.

اگر این متغیر مشخص نشود، مقدار پیش‌فرض آن normal است. تمام نگارش‌های معمول برای مقدار بولی true به عنوان normal و false به عنوان no در نظر گرفته می‌شوند. این متغیر می‌تواند با گزینه -u|--untracked-files در git-status(1) و git-commit(1) بازنویسی شود.

status.submoduleSummary

مقدار پیش‌فرض false است. اگر این متغیر روی یک عدد غیر صفر یا true (معادل با -1 یا یک عدد نامحدود) تنظیم شود، خلاصه زیرماژول فعال شده و خلاصه‌ای از کامیت‌ها برای زیرماژول‌های تغییریافته نشان داده خواهد شد (گزینه --summary-limit در git-submodule(1) را ببینید). لطفاً توجه داشته باشید که خروجی خلاصه برای تمام زیرماژول‌ها زمانی که diff.ignoreSubmodules روی all تنظیم شده باشد متوقف می‌شود، یا تنها برای آن زیرماژول‌هایی که submodule.<name>.ignore=all باشند. تنها استثنای این قاعده این است که status و commit تغییرات مرحله‌بندی‌شده (staged) زیرماژول را نشان خواهند داد. برای مشاهده خلاصه برای زیرماژول‌های نادیده‌گرفته‌شده نیز می‌توانید از گزینه خط فرمان --ignore-submodules=dirty یا دستور git submodule summary استفاده کنید، که خروجی مشابهی را نشان می‌دهد اما به این تنظیمات توجهی نمی‌کند.

submodule.<name>.url

نشانی URL برای یک زیرماژول. این متغیر از طریق git submodule init از فایل .gitmodules در پیکربندی گیت کپی می‌شود. کاربر می‌تواند URL پیکربندی‌شده را پیش از دریافت زیرماژول از طریق git submodule update تغییر دهد. اگر نه submodule.<name>.active و نه submodule.active تنظیم نشده باشند، وجود این متغیر به عنوان یک راه‌حل جایگزین (fallback) استفاده می‌شود تا نشان دهد آیا زیرماژول مورد توجه دستورات گیت هست یا خیر. برای جزئیات به git-submodule(1) و gitmodules(5) مراجعه کنید.

submodule.<name>.update

روشی که زیرماژول توسط git submodule update به‌روزرسانی می‌شود، که تنها دستور تحت تأثیر است و سایر دستورات مانند git checkout --recurse-submodules تحت تأثیر قرار نمی‌گیرند. این متغیر به دلایل تاریخی وجود دارد، زمانی که git submodule تنها دستور برای تعامل با زیرماژول‌ها بود؛ تنظیماتی مانند submodule.active و pull.rebase خاص‌تر هستند. این مقدار توسط git submodule init از فایل gitmodules(5) پر می‌شود. توضیحات دستور update در git-submodule(1) را ببینید.

submodule.<name>.branch

نام شاخه راه دور برای یک زیرماژول، که توسط git submodule update -emote استفاده می‌شود. این گزینه را برای بازنویسی مقدار یافت‌شده در فایل .gitmodules تنظیم کنید. برای جزئیات به git-submodule(1) و gitmodules(5) مراجعه کنید.

submodule.<name>.fetchRecurseSubmodules

این گزینه می‌تواند برای کنترل دریافت بازگشتی این زیرماژول استفاده شود. با استفاده از گزینه خط فرمان --[no-]recurse-submodules در «git fetch» و «git pull» می‌توان آن را لغو و بازنویسی کرد. این تنظیم، مقداری را که در فایل gitmodules(5) قرار دارد بازنویسی می‌کند.

submodule.<name>.ignore

مشخص می‌کند تحت چه شرایطی «git status» و خانواده diff یک زیرماژول را تغییریافته نشان می‌دهند. وقتی روی «all» تنظیم شود، هرگز زیرماژول را تغییریافته در نظر نخواهد گرفت. با این حال می‌توان با استفاده از گزینه -rce آن را استیج کرد که در این صورت در خروجی status ظاهر خواهد شد. هنگامی که روی «dirty» تنظیم شود، تمام تغییرات درخت کاری زیرماژول را نادیده می‌گیرد و تنها تفاوت‌های میان HEAD زیرماژول و کامیت ثبت‌شده در پروژه والد را مد نظر قرار می‌دهد. مقدار «untracked» علاوه بر این اجازه می‌دهد زیرماژول‌هایی که فایل‌های ردیابی‌شدهٔ تغییریافته در درخت کاری خود دارند نشان داده شوند. وقتی روی «none» (پیش‌فرض) تنظیم شود، زیرماژول‌ها را حتی اگر فایل‌های ردیابی‌نشده در درخت کاری خود داشته باشند نیز تغییریافته نشان می‌دهد. این تنظیم هر تنظیمی را که در .gitmodules برای این زیرماژول انجام شده باشد بازنویسی می‌کند؛ هر دو تنظیم را می‌توان در خط فرمان با استفاده از گزینه «-ignore-submodules» بازنویسی کرد. دستورات git submodule تحت تأثیر این تنظیم قرار نمی‌گیرند.

submodule.<name>.active

مقدار بولی که مشخص می‌کند آیا زیرماژول مورد توجه دستورات گیت هست یا خیر. این گزینه پیکربندی بر گزینه پیکربندی submodule.active تقدم دارد. برای جزئیات به gitsubmodules(7) مراجعه کنید.

submodule.<name>.gitdir

این گزینه مسیر gitdir را برای زیرماژول <name> تنظیم می‌کند. این پیکربندی در صورتی رعایت می‌شود که extensions.submodulePathConfig فعال باشد، در غیر این صورت هیچ اثری ندارد. هنگام فعال بودن، این پیکربندی به تنها منبع حقیقت برای مسیرهای gitdir زیرماژول تبدیل می‌شود و در صورت مفقود بودن، گیت خطا صادر می‌کند. برای جزئیات به git-config(1) مراجعه کنید.

submodule.active

یک فیلد تکرارشونده شامل الگوی مسیر (pathspec) که برای تطبیق با مسیر یک زیرماژول استفاده می‌شود تا مشخص کند آیا زیرماژول مورد توجه دستورات گیت هست یا خیر. برای جزئیات به gitsubmodules(7) مراجعه کنید.

submodule.recurse

یک مقدار بولی که مشخص می‌کند آیا دستورات باید گزینه -ecurse-submodules را به صورت پیش‌فرض فعال کنند یا خیر. پیش‌فرض false است.

هنگامی که روی true تنظیم شود، می‌توان آن را از طریق گزینه -0-recurse-submodules غیرفعال کرد. توجه داشته باشید که برخی از دستورات گیت که فاقد این گزینه هستند ممکن است برخی از دستورات فوق را که تحت تأثیر submodule.recurse هستند فراخوانی کنند؛ برای مثال git remote update دستور git fetch را فراخوانی می‌کند اما گزینه -0-recurse-submodules ندارد. برای این دستورات، یک راهکار موقت تغییر مقدار پیکربندی با استفاده از git -c submodule.recurse=0 است.

فهرست زیر دستوراتی را نشان می‌دهد که -ecurse-submodules را می‌پذیرند و اینکه آیا توسط این تنظیم پشتیبانی می‌شوند یا خیر.

•دستورات checkout، fetch، grep، pull، push، read-tree، reset، restore و switch همیشه پشتیبانی می‌شوند.
•دستورات clone و ls-files پشتیبانی نمی‌شوند.
•دستور branch تنها در صورتی پشتیبانی می‌شود که submodule.propagateBranches فعال باشد.

submodule.propagateBranches

[آزمایشی] یک مقدار بولی که پشتیبانی از شاخه‌بندی را هنگام استفاده از -ecurse-submodules یا submodule.recurse=true فعال می‌کند. فعال کردن این گزینه به برخی دستورات اجازه می‌دهد تا -ecurse-submodules را بپذیرند، و برخی دستورات که از قبل -ecurse-submodules را می‌پذیرند اکنون شاخه‌ها را نیز در نظر خواهند گرفت. پیش‌فرض false است.

submodule.fetchJobs

مشخص می‌کند چه تعداد زیرماژول به طور هم‌زمان دریافت/کلون شوند. یک عدد صحیح مثبت اجازه می‌دهد تا آن تعداد زیرماژول به صورت موازی دریافت شوند. مقدار 0 یک پیش‌فرض معقول تعیین می‌کند. در صورت عدم تنظیم، به طور پیش‌فرض 1 است.

submodule.alternateLocation

مشخص می‌کند زیرماژول‌ها هنگام کلون شدن چگونه alternates (منابع جایگزین اشیاء) را به دست می‌آورند. مقادیر مجاز عبارتند از no و superproject. به طور پیش‌فرض no در نظر گرفته می‌شود، که هیچ ارجاعی اضافه نمی‌کند. هنگامی که مقدار روی superproject تنظیم شود، زیرماژولی که قرار است کلون شود مکان alternates خود را نسبت به alternate پروژه والد محاسبه می‌کند.

submodule.alternateErrorStrategy

مشخص می‌کند با خطاهای مربوط به alternates برای یک زیرماژول که از طریق submodule.alternateLocation محاسبه شده است چگونه برخورد شود. مقادیر مجاز عبارتند از ignore، info و die. مقدار پیش‌فرض die است. توجه داشته باشید که اگر روی ignore یا info تنظیم شود، و در alternate محاسبه‌شده خطایی رخ دهد، عملیات کلون طوری ادامه می‌یابد که گویی هیچ alternateای مشخص نشده است.

tag.forceSignAnnotated

یک مقدار بولی برای مشخص کردن اینکه آیا برچسب‌های حاشیه‌نویسی‌شده (annotated tags) ایجادشده باید دارای امضای GPG باشند یا خیر. اگر -nnotate در خط فرمان مشخص شده باشد، بر این گزینه تقدم دارد.

tag.sort

این متغیر ترتیب مرتب‌سازی برچسب‌ها را هنگام نمایش توسط git-tag(1) کنترل می‌کند. بدون ارائه گزینه -rt=<value>، مقدار این متغیر به عنوان پیش‌فرض استفاده خواهد شد.

tag.gpgSign

یک مقدار بولی برای مشخص کردن اینکه آیا همه برچسب‌ها باید با GPG امضا شوند یا خیر. استفاده از این گزینه هنگام اجرا در یک اسکریپت خودکار می‌تواند منجر به امضا شدن تعداد زیادی برچسب شود. بنابراین استفاده از یک agent مناسب است تا از تایپ چندباره عبارت عبور GPG خودداری شود. توجه داشته باشید که این گزینه بر رفتار امضای برچسب که توسط گزینه‌های -u <keyid> یا - فعال شده است تأثیری ندارد.

tar.umask

این متغیر می‌تواند برای محدود کردن بیت‌های مجوز ورودی‌های آرشیو tar استفاده شود. مقدار پیش‌فرض 0002 است که بیت نوشتن همگانی (world write bit) را خاموش می‌کند. مقدار ویژه «user» نشان می‌دهد که umask کاربر آرشیوکننده در عوض استفاده خواهد شد. به umask(2) و git-archive(1) مراجعه کنید.

تنظیمات پیکربندی Trace2 فقط از فایل‌های پیکربندی سیستم و سراسری (global) خوانده می‌شوند؛ فایل‌های پیکربندی محلی مخزن و درخت کاری (worktree) و آرگومان‌های خط فرمان -c نادیده گرفته می‌شوند.

trace2.normalTarget

این متغیر مقصد هدف عادی (normal target) را کنترل می‌کند. ممکن است توسط متغیر محیطی GIT_TRACE2 بازنویسی شود. جدول زیر مقادیر ممکن را نشان می‌دهد.

trace2.perfTarget

این متغیر مقصد هدف کارایی (performance target) را کنترل می‌کند. ممکن است توسط متغیر محیطی GIT_TRACE2_PERF بازنویسی شود. جدول زیر مقادیر ممکن را نشان می‌دهد.

trace2.eventTarget

این متغیر مقصد هدف رویداد (event target) را کنترل می‌کند. ممکن است توسط متغیر محیطی GIT_TRACE2_EVENT بازنویسی شود. جدول زیر مقادیر ممکن را نشان می‌دهد.
•0 یا false - هدف را غیرفعال می‌کند.
•1 یا true - در STDERR می‌نویسد.
•[2-9] - در توصیف‌گر فایل (file descriptor) که از قبل باز شده می‌نویسد.
•<absolute-pathname> - در حالت الحاق (append mode) درون فایل می‌نویسد. اگر هدف از قبل موجود باشد و یک دایرکتوری باشد، ردگیری‌ها در فایل‌هایی (یک فایل برای هر فرایند) زیر دایرکتوری داده‌شده نوشته می‌شوند.
•af_unix:[<socket-type>:]<absolute-pathname> - در یک Unix Domain Socket می‌نویسد (روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند). نوع سوکت می‌تواند stream یا dgram باشد؛ در صورت حذف، گیت هر دو را امتحان خواهد کرد.

trace2.normalBrief

بولی. هنگامی که true باشد، فیلدهای time، filename و line از خروجی عادی حذف می‌شوند. ممکن است توسط متغیر محیطی GIT_TRACE2_BRIEF بازنویسی شود. پیش‌فرض false است.

trace2.perfBrief

بولی. هنگامی که true باشد، فیلدهای time، filename و line از خروجی PERF حذف می‌شوند. ممکن است توسط متغیر محیطی GIT_TRACE2_PERF_BRIEF بازنویسی شود. پیش‌فرض false است.

trace2.eventBrief

بولی. هنگامی که true باشد، فیلدهای time، filename و line از خروجی رویداد (event) حذف می‌شوند. ممکن است توسط متغیر محیطی GIT_TRACE2_EVENT_BRIEF بازنویسی شود. پیش‌فرض false است.

trace2.eventNesting

عدد صحیح. عمق مورد نظر ناحیه‌های تودرتو را در خروجی رویداد مشخص می‌کند. ناحیه‌های عمیق‌تر از این مقدار حذف خواهند شد. ممکن است توسط متغیر محیطی GIT_TRACE2_EVENT_NESTING بازنویسی شود. پیش‌فرض 2 است.

trace2.configParams

فهرستی جداشده با کاما از الگوهای تنظیمات پیکربندی «مهم» که باید در خروجی trace2 ثبت شوند. برای مثال، core.*,remote.*.url باعث می‌شود خروجی trace2 حاوی رویدادهایی باشد که هر ریموت پیکربندی‌شده را فهرست می‌کند. ممکن است توسط متغیر محیطی GIT_TRACE2_CONFIG_PARAMS بازنویسی شود. به طور پیش‌فرض تنظیم نشده است.

trace2.envVars

فهرستی جداشده با کاما از متغیرهای محیطی «مهم» که باید در خروجی trace2 ثبت شوند. برای مثال، GIT_HTTP_USER_AGENT,GIT_CONFIG باعث می‌شود خروجی trace2 حاوی رویدادهایی باشد که بازنویسی‌های عامل کاربر HTTP و مکان فایل پیکربندی گیت را فهرست می‌کند (به فرض اینکه تنظیمی صورت گرفته باشد). ممکن است توسط متغیر محیطی GIT_TRACE2_ENV_VARS بازنویسی شود. به طور پیش‌فرض تنظیم نشده است.

trace2.destinationDebug

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

trace2.maxFiles

عدد صحیح. هنگام نوشتن فایل‌های ردگیری در یک دایرکتوری هدف، اگر انجام این کار از این تعداد فایل فراتر رود، ردگیری‌های بیشتری ننویسید. در عوض، یک فایل نشانگر (sentinel file) بنویسید که از ادامه ردگیری در این دایرکتوری جلوگیری کند. پیش‌فرض 0 است که این بررسی را غیرفعال می‌کند.

trailer.separators

این گزینه مشخص می‌کند چه نویسه‌هایی به عنوان جداکننده پی‌نوشت (trailer separator) شناخته شوند. به طور پیش‌فرض تنها : به عنوان جداکننده پی‌نوشت شناخته می‌شود، با این استثنا که = برای سازگاری با سایر دستورات گیت همیشه در خط فرمان پذیرفته می‌شود.

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

برای مثال، اگر مقدار این گزینه %=$ باشد، آنگاه تنها خطوطی که از قالب <key><sep><value> استفاده می‌کنند که در آن <sep> شامل %، = یا $ و سپس فاصله باشد، به عنوان پی‌نوشت در نظر گرفته خواهند شد. و % جداکننده پیش‌فرض مورد استفاده خواهد بود، بنابراین به طور پیش‌فرض پی‌نوشت‌ها به این صورت ظاهر می‌شوند: <key>% <value> (یک علامت درصد و یک فاصله بین کلید و مقدار قرار خواهد گرفت).

trailer.where

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

این مقدار می‌تواند end (که پیش‌فرض است)، start، after یا before باشد.

اگر end باشد، هر پی‌نوشت جدید در انتهای پی‌نوشت‌های موجود ظاهر می‌شود.

اگر start باشد، هر پی‌نوشت جدید به جای انتها در ابتدای پی‌نوشت‌های موجود ظاهر خواهد شد.

اگر after باشد، هر پی‌نوشت جدید دقیقاً پس از آخرین پی‌نوشت با همان <key> ظاهر می‌شود.

اگر before باشد، هر پی‌نوشت جدید دقیقاً قبل از اولین پی‌نوشت با همان <key> ظاهر می‌شود.

trailer.ifexists

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

مقادیر معتبر برای این گزینه عبارتند از: addIfDifferentNeighbor (این مقدار پیش‌فرض است)، addIfDifferent، add، replace یا doNothing.

با addIfDifferentNeighbor، یک پی‌نوشت جدید تنها در صورتی اضافه می‌شود که هیچ پی‌نوشتی با همان جفت (<key>, <value>) در خط بالاتر یا پایین‌تر از مکانی که پی‌نوشت جدید اضافه می‌شود نباشد.

با addIfDifferent، یک پی‌نوشت جدید تنها در صورتی اضافه خواهد شد که هیچ پی‌نوشتی با همان جفت (<key>, <value>) از قبل در ورودی وجود نداشته باشد.

با add، یک پی‌نوشت جدید اضافه خواهد شد، حتی اگر پی‌نوشت‌هایی با همان جفت (<key>, <value>) از قبل در ورودی وجود داشته باشند.

با replace، پی‌نوشت موجود با همان <key> حذف شده و پی‌نوشت جدید اضافه خواهد شد. پی‌نوشت حذف‌شده نزدیک‌ترین پی‌نوشت (با همان <key>) به مکانی خواهد بود که پی‌نوشت جدید اضافه می‌شود.

با doNothing، هیچ کاری انجام نخواهد شد؛ یعنی اگر پی‌نوشتی با همان <key> در ورودی وجود داشته باشد هیچ پی‌نوشت جدیدی اضافه نمی‌شود.

trailer.ifmissing

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

مقادیر معتبر برای این گزینه عبارتند از: add (پیش‌فرض) و doNothing.

با add، یک پی‌نوشت جدید اضافه خواهد شد.

با doNothing، هیچ کاری انجام نخواهد شد.

trailer.<key-alias>.key

یک <key-alias> را برای <key> تعریف می‌کند. مقدار <key-alias> باید یک پیشوند (بدون حساسیت به بزرگی و کوچکی حروف) از <key> باشد. برای مثال، در git config trailer.ack.key «Acked-by»، مقدار Acked-by همان <key> است و ack همان <key-alias> می‌باشد. این پیکربندی امکان فراخوانی کوتاه‌تر -railer «ack:...» را در خط فرمان با استفاده از <key-alias> «ack» به جای عبارت طولانی‌تر -railer «Acked-by:...» فراهم می‌کند.

در انتهای <key>، یک جداکننده و سپس چند نویسه فاصله می‌تواند قرار گیرد. به طور پیش‌فرض تنها جداکننده معتبر : است، اما می‌توان با استفاده از متغیر پیکربندی trailer.separators آن را تغییر داد.

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

trailer.<key-alias>.where

این گزینه همان مقادیر متغیر پیکربندی trailer.where را می‌پذیرد و آنچه را که توسط آن گزینه برای پی‌نوشت‌های دارای <key-alias> مشخص‌شده تعیین شده است بازنویسی می‌کند.

trailer.<key-alias>.ifexists

این گزینه همان مقادیر متغیر پیکربندی trailer.ifexists را می‌پذیرد و آنچه را که توسط آن گزینه برای پی‌نوشت‌های دارای <key-alias> مشخص‌شده تعیین شده است بازنویسی می‌کند.

trailer.<key-alias>.ifmissing

این گزینه همان مقادیر متغیر پیکربندی trailer.ifmissing را می‌پذیرد و آنچه را که توسط آن گزینه برای پی‌نوشت‌های دارای <key-alias> مشخص‌شده تعیین شده است بازنویسی می‌کند.

trailer.<key-alias>.command

منسوخ شده به نفع trailer.<key-alias>.cmd. این گزینه به همان شیوه trailer.<key-alias>.cmd رفتار می‌کند، با این استثنا که هیچ چیز را به عنوان آرگومان به دستور مشخص‌شده ارسال نمی‌کند. در عوض اولین وقوع زیررشته $ARG با <value> که قرار بود به عنوان آرگومان ارسال شود جایگزین می‌شود.

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

هنگامی که هر دو گزینه trailer.<key-alias>.cmd و trailer.<key-alias>.command برای یک <key-alias> داده شوند، trailer.<key-alias>.cmd استفاده می‌شود و trailer.<key-alias>.command نادیده گرفته خواهد شد.

trailer.<key-alias>.cmd

این گزینه می‌تواند برای تعیین یک دستور پوسته استفاده شود که یک بار برای افزودن خودکار یک پی‌نوشت با <key-alias> مشخص‌شده فراخوانی می‌شود، و سپس هر بار که یک آرگومان -railer <key-alias>=<value> برای اصلاح <value> پی‌نوشتی که این گزینه تولید می‌کند مشخص شود، فراخوانی خواهد شد.

هنگامی که دستور مشخص‌شده برای اولین بار جهت افزودن یک پی‌نوشت با <key-alias> مشخص‌شده فراخوانی می‌شود، رفتار به گونه‌ای است که گویی یک آرگومان ویژه -railer <key-alias>=<value> در ابتدای git-interpret-trailers(1) اضافه شده باشد، که در آن <value> خروجی استاندارد دستور پس از حذف فاصله‌های خالی ابتدا و انتها در نظر گرفته می‌شود.

اگر برخی آرگومان‌های -railer <key-alias>=<value> نیز در خط فرمان ارسال شوند، دستور مجدداً برای هر یک از این آرگومان‌ها با همان <key-alias> یک بار فراخوانی می‌شود. و بخش <value> این آرگومان‌ها، در صورت وجود، به عنوان اولین آرگومان به دستور ارسال خواهد شد. به این ترتیب دستور می‌تواند یک <value> تولید کند که از <value> ارسال‌شده در آرگومان -railer <key-alias>=<value> محاسبه شده است.

transfer.credentialsInUrl

یک نشانی URL پیکربندی‌شده می‌تواند شامل اعتبارنامه‌های متنی ساده (plaintext credentials) به شکل <protocol>://<user>:<password>@<domain>/<path> باشد. ممکن است بخواهید درباره استفاده از چنین پیکربندی هشدار دهید یا آن را ممنوع کنید (به نفع استفاده از git-credential(1)). این گزینه در git-clone(1)، git-fetch(1)، git-push(1) و هرگونه استفاده مستقیم دیگر از URL پیکربندی‌شده اعمال خواهد شد.

توجه داشته باشید که این ویژگی در حال حاضر محدود به تشخیص اعتبارنامه‌ها در پیکربندی remote.<name>.url است؛ و اعتبارنامه‌ها را در پیکربندی remote.<name>.pushurl تشخیص نخواهد داد.

شاید بخواهید این ویژگی را برای جلوگیری از افشای سهوی اعتبارنامه‌ها فعال کنید، برای مثال به این دلایل:

•سیستم‌عامل یا سیستمی که گیت را روی آن اجرا می‌کنید ممکن است راهی برای پیکربندی دسترسی‌های فایل پیکربندی که نام کاربری و/یا گذرواژه در آن ذخیره شده است ارائه ندهد یا به شما اجازه این کار را ندهد.
•حتی اگر این کار را انجام دهد، ذخیره چنین داده‌هایی به صورت ساکن («at rest») ممکن است شما را از روش‌های دیگر در معرض خطر قرار دهد، برای مثال یک فرآیند پشتیبان‌گیری ممکن است داده‌ها را به سیستم دیگری کپی کند.
•برنامه‌های گیت نشانی URL کامل را به عنوان آرگومان در خط فرمان به یکدیگر ارسال می‌کنند، به این معنی که اعتبارنامه‌ها در سیستم‌هایی که به سایر کاربران غیرممتاز اجازه می‌دهند فهرست کامل فرآیندهای دیگران را ببینند، افشا خواهد شد. در لینوکس تنظیم «hidepid» که در procfs(5) مستند شده است امکان پیکربندی این رفتار را فراهم می‌کند.

اگر چنین نگرانی‌هایی در مورد شما صدق نمی‌کند، احتمالاً نیازی نیست نگران افشای اعتبارنامه‌ها به دلیل ذخیره داده‌های حساس در فایل‌های پیکربندی گیت باشید. اگر می‌خواهید از این ویژگی استفاده کنید، transfer.credentialsInUrl را روی یکی از این مقادیر تنظیم کنید:

•allow (پیش‌فرض): گیت بدون هشدار به فعالیت خود ادامه می‌دهد.
•warn: گیت هنگام تجزیه یک URL با اعتبارنامه متنی ساده، یک پیام هشدار در stderr می‌نویسد.
•die: گیت هنگام تجزیه یک URL با اعتبارنامه متنی ساده، یک پیام شکست در stderr می‌نویسد.

transfer.fsckObjects

هنگامی که fetch.fsckObjects یا receive.fsckObjects تنظیم نشده باشند، مقدار این متغیر در عوض استفاده می‌شود. پیش‌فرض false است.

هنگام تنظیم، عملیات fetch یا receive در صورت وجود شیء معیوب یا پیوند به یک شیء ناموجود متوقف می‌شود. علاوه بر این، مسائل مختلف دیگری نیز بررسی می‌شوند، از جمله مشکلات موروثی (به fsck.<msg-id> مراجعه کنید)، و مسائل امنیتی احتمالی مانند وجود دایرکتوری .GIT یا یک فایل مخرب .gitmodules (برای جزئیات به یادداشت‌های انتشار نسخه‌های v2.2.1 و v2.17.1 مراجعه کنید). سایر بررسی‌های سلامت و امنیت ممکن است در انتشارهای آینده اضافه شوند.

در سمت دریافت‌کننده، ناموفق بودن fsckObjects باعث غیرقابل‌دسترس شدن آن اشیاء می‌شود، بخش «QUARANTINE ENVIRONMENT» را در git-receive-pack(1) ببینید. در سمت fetch، اشیاء معیوب در عوض به صورت بدون ارجاع در مخزن باقی می‌مانند.

با توجه به ماهیت غیرقرنطینه‌ای پیاده‌سازی fetch.fsckObjects، نمی‌توان مانند receive.fsckObjects اطمینان داشت که مخزن اشیاء (object store) را تمیز باقی می‌گذارد.

از آنجا که اشیاء هنگام باز شدن بسته‌ها در مخزن اشیاء نوشته می‌شوند، مواردی وجود دارد که در آن اشیاء مخرب حتی با وجود شکست «fetch» وارد سیستم می‌شوند، و سپس یک «fetch» بعدی موفق می‌شود زیرا فقط اشیاء جدید ورودی بررسی می‌شوند، نه آن‌هایی که قبلاً در مخزن اشیاء نوشته شده‌اند. نباید به این تفاوت در رفتار اتکا کرد. در آینده، ممکن است چنین اشیائی برای «fetch» نیز قرنطینه شوند.

در حال حاضر، افراد بسیار محتاط در صورتی که محافظتی مشابه «push» بخواهند باید راهی برای شبیه‌سازی محیط قرنطینه بیابند. به عنوان مثال، در مورد یک آینه (mirror) داخلی، آینه‌سازی را در دو مرحله انجام دهید: یکی برای دریافت اشیاء غیرقابل‌اعتماد، و سپس یک «push» دوم (که از قرنطینه استفاده خواهد کرد) به یک مخزن داخلی دیگر، و از کلاینت‌های داخلی بخواهید از این مخزن push‌شده استفاده کنند؛ یا دریافت‌های داخلی را متوقف کنید و تنها زمانی به آن‌ها اجازه دهید که یک «fsck» کامل اجرا شده باشد (و در این فاصله هیچ fetch جدیدی رخ نداده باشد).

transfer.hideRefs

رشته(هایی) که receive-pack و upload-pack برای تصمیم‌گیری در مورد اینکه چه مراجعی (refs) از اعلان‌های اولیه آن‌ها حذف شوند استفاده می‌کنند. برای مشخص کردن چندین رشته پیشوندی از بیش از یک تعریف استفاده کنید. مرجعی که زیر سلسله‌مراتب‌های فهرست‌شده در مقدار این متغیر باشد مستثنی شده و هنگام پاسخ دادن به git push یا git fetch مخفی می‌شود. برای نسخه‌های ویژه‌برنامه این پیکربندی به receive.hideRefs و uploadpack.hideRefs مراجعه کنید.

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

اگر یک فضای نام (namespace) در حال استفاده باشد، پیشوند فضای نام قبل از تطبیق با الگوهای transfer.hiderefs از هر مرجع حذف می‌شود. به منظور تطبیق مراجع قبل از حذف پیشوند، یک ^ در ابتدای نام مرجع اضافه کنید. اگر ! و ^ را ترکیب می‌کنید، ابتدا باید ! مشخص شود.

برای مثال، اگر refs/heads/master در transfer.hideRefs مشخص شده باشد و فضای نام فعلی foo باشد، آنگاه refs/namespaces/foo/refs/heads/master از اعلان‌ها حذف می‌شود. اگر uploadpack.allowRefInWant تنظیم شده باشد، upload-pack در دستور fetch تحت پروتکل نسخه ۲ با want-ref refs/heads/master طوری برخورد می‌کند که گویی refs/namespaces/foo/refs/heads/master وجود نداشته است. از طرف دیگر، receive-pack همچنان شناسه شیئی را که مرجع به آن اشاره می‌کند بدون ذکر نام آن اعلان می‌کند (یک خط اصطلاحاً «.have»).

حتی اگر مراجع را مخفی کنید، کلاینت ممکن است همچنان بتواند اشیاء هدف را از طریق تکنیک‌های شرح داده شده در بخش «SECURITY» صفحه راهنمای gitnamespaces(7) برباید؛ بهتر است داده‌های خصوصی در یک مخزن جداگانه نگهداری شوند.

transfer.unpackLimit

هنگامی که fetch.unpackLimit یا receive.unpackLimit تنظیم نشده باشند، مقدار این متغیر در عوض استفاده می‌شود. مقدار پیش‌فرض 100 است.

transfer.advertiseSID

بولی. هنگامی که true باشد، فرایندهای کلاینت و سرور شناسه‌های یکتای نشست (session IDs) خود را به همتای راه دور خود اعلان می‌کنند. پیش‌فرض false است.

transfer.bundleURI

هنگامی که true باشد، دستورات محلی git clone اطلاعات بسته (bundle) را از سرور راه دور (در صورت اعلان) درخواست کرده و قبل از ادامه شبیه‌سازی از طریق پروتکل گیت، بسته‌ها را بارگیری می‌کنند. پیش‌فرض false است.

transfer.advertiseObjectInfo

هنگامی که true باشد، قابلیت object-info توسط سرورها اعلان می‌شود. پیش‌فرض false است.

uploadarchive.allowUnreachable

اگر true باشد، به کلاینت‌ها اجازه می‌دهد از git archive -emote برای درخواست هر درختی، چه از نوک مراجع قابل دسترس باشد و چه نباشد، استفاده کنند. برای جزئیات بیشتر به توضیحات بخش «SECURITY» در git-upload-archive(1) مراجعه کنید. پیش‌فرض false است.

uploadpack.hideRefs

این متغیر مشابه transfer.hideRefs است، اما تنها بر upload-pack اعمال می‌شود (و بنابراین تنها بر fetchها تأثیر می‌گذارد، نه pushها). تلاش برای fetch کردن یک مرجع مخفی توسط git fetch شکست خواهد خورد. همچنین به uploadpack.allowTipSHA1InWant مراجعه کنید.

uploadpack.allowTipSHA1InWant

هنگامی که uploadpack.hideRefs فعال است، به upload-pack اجازه می‌دهد تا درخواست fetch که شیئی در نوک یک مرجع مخفی را می‌خواهد بپذیرد (به طور پیش‌فرض، چنین درخواستی رد می‌شود). همچنین به uploadpack.hideRefs مراجعه کنید. حتی اگر این مقدار false باشد، یک کلاینت ممکن است بتواند از طریق تکنیک‌های شرح داده شده در بخش «SECURITY» صفحه راهنمای gitnamespaces(7) اشیاء را برباید؛ بهتر است داده‌های خصوصی در یک مخزن جداگانه نگهداری شوند.

uploadpack.allowReachableSHA1InWant

به upload-pack اجازه می‌دهد تا درخواست fetch که شیئی قابل دسترس از هر نوک مرجعی را می‌خواهد بپذیرد. با این حال، توجه داشته باشید که محاسبه دسترسی‌پذیری شیء از نظر محاسباتی سنگین است. پیش‌فرض false است. حتی اگر این مقدار false باشد، یک کلاینت ممکن است بتواند از طریق تکنیک‌های شرح داده شده در بخش «SECURITY» صفحه راهنمای gitnamespaces(7) اشیاء را برباید؛ بهتر است داده‌های خصوصی در یک مخزن جداگانه نگهداری شوند.

uploadpack.allowAnySHA1InWant

به upload-pack اجازه می‌دهد تا درخواست fetch برای هر شیئی را بپذیرد. این گزینه مستلزم uploadpack.allowTipSHA1InWant و uploadpack.allowReachableSHA1InWant است. اگر روی true تنظیم شود هر دوی آن‌ها را فعال می‌کند، و اگر روی false تنظیم شود هر دوی آن‌ها را غیرفعال می‌کند. به طور پیش‌فرض تنظیم نشده است.

uploadpack.keepAlive

هنگامی که upload-pack دستور pack-objects را آغاز کرده باشد، ممکن است یک دوره سکوت در زمانی که pack-objects بسته را آماده می‌کند وجود داشته باشد. در حالت عادی اطلاعات پیشرفت را خروجی می‌دهد، اما اگر از گزینه -quiet برای fetch استفاده شده باشد، pack-objects تا زمان شروع ارسال داده‌های بسته مطلقاً چیزی خروجی نخواهد داد. برخی کلاینت‌ها و شبکه‌ها ممکن است سرور را متوقف‌شده (hung) تلقی کرده و ارتباط را قطع کنند. تنظیم این گزینه به upload-pack دستور می‌دهد هر uploadpack.keepAlive ثانیه یک بسته خالی زنده نگه‌داشتن (keepalive packet) ارسال کند. تنظیم این گزینه روی 0 بسته‌های keepalive را به طور کامل غیرفعال می‌کند. پیش‌فرض 5 ثانیه است.

uploadpack.packObjectsHook

اگر این گزینه تنظیم شده باشد، هنگامی که upload-pack بخواهد git pack-objects را برای ایجاد یک فایل بسته (packfile) برای کلاینت اجرا کند، در عوض این دستور پوسته را اجرا خواهد کرد. دستور pack-objects و آرگومان‌هایی که می‌بایست اجرا می‌شدند (شامل git pack-objects در ابتدا) به انتهای دستور پوسته ضمیمه می‌شوند. ورودی استاندارد (stdin) و خروجی استاندارد (stdout) قلاب به گونه‌ای مدیریت می‌شوند که گویی خود pack-objects اجرا شده است؛ یعنی upload-pack ورودی در نظر گرفته‌شده برای pack-objects را به قلاب می‌دهد و انتظار یک فایل بسته کامل را در stdout دارد.

توجه داشته باشید که این متغیر پیکربندی تنها زمانی رعایت می‌شود که در پیکربندی محافظت‌شده مشخص شده باشد (بخش موسوم به “SCOPES” را ببینید). این یک اقدام ایمنی در برابر دریافت از مخازن غیرقابل‌اعتماد است.

uploadpack.allowFilter

اگر این گزینه تنظیم شود، upload-pack از کلون جزئی (partial clone) و فیلتر کردن اشیاء در دریافت جزئی (partial fetch) پشتیبانی خواهد کرد.

uploadpackfilter.allow

یک مقدار پیش‌فرض برای فیلترهای شیء تعیین‌نشده ارائه می‌دهد (متغیر پیکربندی زیر را ببینید). اگر روی true تنظیم شود، همه فیلترهایی را که در آینده اضافه می‌شوند نیز فعال خواهد کرد. پیش‌فرض true است.

uploadpackfilter.<filter>.allow

صراحتاً فیلتر شیء متناظر با <filter> را مجاز یا ممنوع می‌کند، که در آن <filter> می‌تواند یکی از موارد زیر باشد: blob:none، blob:limit، object:type، tree، sparse:oid یا combine. در صورت استفاده از فیلترهای ترکیبی، هم combine و هم تمام انواع فیلترهای تودرتو باید مجاز باشند. پیش‌فرض uploadpackfilter.allow است.

uploadpackfilter.tree.maxDepth

تنها زمانی -lter=tree:<n> را مجاز می‌داند که <n> بیشتر از مقدار uploadpackfilter.tree.maxDepth نباشد. در صورت تنظیم، این گزینه همچنین مستلزم uploadpackfilter.tree.allow=true است، مگر اینکه این متغیر پیکربندی از قبل تنظیم شده باشد. در صورت عدم تنظیم هیچ اثری ندارد.

uploadpack.allowRefInWant

اگر این گزینه تنظیم شود، upload-pack از قابلیت ref-in-want دستور fetch در پروتکل نسخه ۲ پشتیبانی خواهد کرد. این قابلیت به نفع سرورهای با موازنه‌بار (load-balanced) در نظر گرفته شده است که ممکن است به دلیل تأخیر در همانندسازی (replication delay)، دیدگاه یکسانی از اینکه مراجع آن‌ها به چه OIDهایی اشاره می‌کنند نداشته باشند.

url.<base>.insteadOf

هر نشانی URL که با این مقدار شروع شود بازنویسی می‌شود تا در عوض با <base> شروع شود. در مواردی که یک سایت تعداد زیادی مخزن را میزبانی می‌کند و آن‌ها را با چندین روش دسترسی ارائه می‌دهد، و برخی کاربران نیاز به استفاده از روش‌های دسترسی متفاوتی دارند، این قابلیت به افراد اجازه می‌دهد هر یک از URLهای معادل را مشخص کنند و گیت به طور خودکار URL را به بهترین جایگزین برای آن کاربر خاص بازنویسی کند، حتی برای مخزنی در آن سایت که قبلاً هرگز دیده نشده است. هنگامی که بیش از یک رشته insteadOf با یک URL مطابقت داشته باشد، طولانی‌ترین تطابق استفاده می‌شود.

توجه داشته باشید که هرگونه محدودیت پروتکل بر URL بازنویسی‌شده اعمال خواهد شد. اگر بازنویسی، URL را برای استفاده از یک پروتکل سفارشی یا دستیار راه دور (remote helper) تغییر دهد، ممکن است لازم باشد پیکربندی protocol.*.allow را برای مجاز کردن درخواست تنظیم کنید. به ویژه، پروتکل‌هایی که انتظار دارید برای زیرماژول‌ها استفاده کنید باید به جای مقدار پیش‌فرض user روی always تنظیم شوند. توضیحات protocol.allow در بالا را ببینید.

url.<base>.pushInsteadOf

به هر نشانی URL که با این مقدار شروع شود داده‌ای push نخواهد شد؛ در عوض، بازنویسی می‌شود تا با <base> شروع شود، و به URL حاصل push انجام می‌شود. در مواردی که یک سایت تعداد زیادی مخزن را با چندین روش دسترسی میزبانی می‌کند، که برخی از آن‌ها اجازه push را نمی‌دهند، این قابلیت به افراد اجازه می‌دهد یک URL فقط-دریافتی (pull-only) مشخص کنند و گیت به طور خودکار از یک URL مناسب برای push استفاده کند، حتی برای مخزنی در آن سایت که قبلاً هرگز دیده نشده است. هنگامی که بیش از یک رشته pushInsteadOf با یک URL مطابقت داشته باشد، طولانی‌ترین تطابق استفاده می‌شود. اگر یک ریموت دارای یک pushurl صریح باشد، گیت این تنظیم را برای آن ریموت نادیده خواهد گرفت.

user.name, user.email, author.name, author.email, committer.name, committer.email

متغیرهای user.name و user.email تعیین می‌کنند چه مقادیری در فیلدهای author (نویسنده) و committer (ثبت‌کننده) اشیاء کامیت قرار گیرند. اگر نیاز دارید که author یا committer متفاوت باشند، می‌توان متغیرهای author.name، author.email، committer.name یا committer.email را تنظیم کرد. همه این موارد را می‌توان با متغیرهای محیطی GIT_AUTHOR_NAME، GIT_AUTHOR_EMAIL، GIT_COMMITTER_NAME، GIT_COMMITTER_EMAIL و EMAIL بازنویسی کرد.

توجه داشته باشید که اشکال name این متغیرها به طور معمول به نوعی نام شخصی اشاره دارند. برای اطلاعات بیشتر در مورد این تنظیمات به git-commit(1) و بخش متغیرهای محیطی در git(1) مراجعه کنید، و در صورتی که به دنبال اعتبارنامه‌های احراز هویت هستید، به گزینه credential.username نگاه کنید.

user.useConfigOnly

به گیت دستور می‌دهد از تلاش برای حدس زدن مقادیر پیش‌فرض برای user.email و user.name خودداری کند، و در عوض مقادیر را تنها از پیکربندی بازیابی کند. برای مثال، اگر چندین نشانی ایمیل دارید و مایلید برای هر مخزن از یک ایمیل متفاوت استفاده کنید، با تنظیم این گزینه پیکربندی روی true در پیکربندی سراسری همراه با یک نام، گیت قبل از ایجاد کامیت‌های جدید در یک مخزن تازه کلون‌شده از شما درخواست می‌کند ایمیلی را تنظیم کنید. پیش‌فرض false است.

user.signingKey

اگر git-tag(1) یا git-commit(1) هنگام ایجاد یک برچسب یا کامیت امضاشده کلیدی را که می‌خواهید به طور خودکار انتخاب نمی‌کند، می‌توانید انتخاب پیش‌فرض را با این متغیر بازنویسی کنید. این گزینه بدون تغییر به پارامتر -rmat روی ssh تنظیم شده باشد، این مقدار می‌تواند حاوی مسیر کلید خصوصی ssh شما یا کلید عمومی در هنگام استفاده از ssh-agent باشد. به عنوان جایگزین، می‌تواند مستقیماً حاوی یک کلید عمومی با پیشوند key:: باشد (مانند: «key::ssh-rsa XXXXXX identifier»). کلید خصوصی باید از طریق ssh-agent در دسترس باشد. اگر تنظیم نشده باشد، گیت gpg.ssh.defaultKeyCommand را فراخوانی می‌کند (مانند: «ssh-add -L») و تلاش می‌کند از اولین کلید موجود استفاده کند. برای سازگاری با گذشته، کلید خامی که با «-ssh» شروع شود، مانند «ssh-rsa XXXXXX identifier»، به صورت «key::ssh-rsa XXXXXX identifier» در نظر گرفته می‌شود، اما این قالب منسوخ شده است؛ در عوض از قالب key:: استفاده کنید.

versionsort.prereleaseSuffix (deprecated)

نام مستعار منسوخ‌شده برای versionsort.suffix. در صورت تنظیم بودن versionsort.suffix نادیده گرفته می‌شود.

versionsort.suffix

حتی زمانی که مرتب‌سازی نسخه‌ای در git-tag(1) استفاده می‌شود، نام برچسب‌های دارای نسخه پایه یکسان اما پسوندهای متفاوت همچنان به صورت لغت‌نامه‌ای (lexicographically) مرتب می‌شوند، که برای مثال منجر به ظاهر شدن برچسب‌های پیش‌انتشار پس از انتشار اصلی می‌شود (مانند «1.0-rc1» بعد از «1.0»). این متغیر را می‌توان برای تعیین ترتیب مرتب‌سازی برچسب‌های دارای پسوندهای مختلف مشخص کرد.

با تعیین یک پسوند منفرد در این متغیر، هر نام برچسب شامل آن پسوند قبل از انتشار اصلی مربوطه ظاهر خواهد شد. برای مثال، اگر این متغیر روی «-rc» تنظیم شود، تمام برچسب‌های «1.0-rcX» قبل از «1.0» ظاهر می‌شوند. در صورت تعیین چندباره، هر بار برای یک پسوند، ترتیب پسوندها در پیکربندی، ترتیب مرتب‌سازی نام برچسب‌های دارای آن پسوندها را تعیین خواهد کرد. برای مثال، اگر «-pre» قبل از «-rc» در پیکربندی ظاهر شود، تمام برچسب‌های «1.0-preX» قبل از هر برچسب «1.0-rcX» فهرست می‌شوند. جایگاه برچسب انتشار اصلی نسبت به برچسب‌های دارای پسوندهای گوناگون را می‌توان با تعیین پسوند خالی در میان آن پسوندهای دیگر تعیین کرد. برای مثال اگر پسوندهای «-rc»، «»، «-ck» و «-bfs» به همین ترتیب در پیکربندی ظاهر شوند، ابتدا همه برچسب‌های «v4.8-rcX» فهرست می‌شوند، پس از آن «v4.8»، سپس «v4.8-ckX» و در نهایت «v4.8-bfsX».

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

web.browser

یک مرورگر وب را مشخص می‌کند که ممکن است توسط برخی دستورات استفاده شود. در حال حاضر فقط git-instaweb(1) و git-help(1) ممکن است از آن استفاده کنند.

worktree.guessRemote

اگر هیچ شاخه‌ای مشخص نشده باشد و هیچ‌کدام از -b، -B یا -etach استفاده نشده باشند، git worktree add به طور پیش‌فرض یک شاخه جدید از HEAD ایجاد می‌کند. اگر worktree.guessRemote روی true تنظیم شده باشد، worktree add تلاش می‌کند یک شاخه ردیابی راه دور (remote-tracking branch) را پیدا کند که نام آن به طور یکتا با نام شاخه جدید مطابقت داشته باشد. اگر چنین شاخه‌ای وجود داشته باشد، checkout شده و به عنوان «upstream» برای شاخه جدید تنظیم می‌شود. اگر چنین تطابقی یافت نشود، به ایجاد یک شاخه جدید از HEAD فعلی بازمی‌گردد.

worktree.useRelativePaths

پیوند دادن درخت‌های کاری با استفاده از مسیرهای نسبی (هنگامی که «true») یا مسیرهای مطلق (هنگامی که «false»). این امر به ویژه برای ساختارهایی مفید است که در آن‌ها مخزن و درخت‌های کاری ممکن است بین مکان‌ها یا محیط‌های مختلف جابه‌جا شوند. پیش‌فرض «false» است.

توجه داشته باشید که تنظیم worktree.useRelativePaths روی «true» به معنای فعال‌سازی پیکربندی extensions.relativeWorktrees است (به git-config(1) مراجعه کنید)، که در نتیجه آن را با نسخه‌های قدیمی‌تر گیت ناسازگار می‌سازد.

هنگام استفاده از نحو منسوخ‌شده [section.subsection]، اگر زیربخش (subsection) حداقل با یک نویسه بزرگ ارائه شده باشد، تغییر یک مقدار به جای تغییر دادن، منجر به افزودن یک کلید چندخطی خواهد شد. برای مثال وقتی پیکربندی به این صورت باشد

[section.subsection]
  key = value1

و اجرای git config section.Subsection.key value2 منجر خواهد شد به

[section.subsection]
  key = value1
  key = value2

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

1.
سند طراحی bundle URI
file:///usr/share/doc/git-doc/technical/bundle-uri.html
2026-06-29 Git 2.55.0