SYNOPSIS

git config [<file-option>] [--type=<type>] [--fixed-value] [--show-origin] [--show-scope] [-z|--null] name [value [value-pattern]]
git config [<file-option>] [--type=<type>] --add name value
git config [<file-option>] [--type=<type>] [--fixed-value] --replace-all name value [value-pattern]
git config [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get name [value-pattern]
git config [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get-all name [value-pattern]
git config [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] [--name-only] --get-regexp name_regex [value-pattern]
git config [<file-option>] [--type=<type>] [-z|--null] --get-urlmatch name URL
git config [<file-option>] [--fixed-value] --unset name [value-pattern]
git config [<file-option>] [--fixed-value] --unset-all name [value-pattern]
git config [<file-option>] --rename-section old_name new_name
git config [<file-option>] --remove-section name
git config [<file-option>] [--show-origin] [--show-scope] [-z|--null] [--name-only] -l | --list
git config [<file-option>] --get-color name [default]
git config [<file-option>] --get-colorbool name [stdout-is-tty]
git config [<file-option>] -e | --edit

DESCRIPTION

このコマンドを使用して、オプションを照会(query)/設定(set)/置換(replace)/設定解除(unset;削除)できます。名前は実際にはドットで区切られたセクションとキーであり、値はエスケープされます。

--add オプションを使用すると、オプションに複数の行を追加できます。複数行で発生する可能性のあるオプションを更新または設定解除する場合は、value-pattern ( --fixed-value オプションが指定されていない限り、拡張正規表現)を指定する必要があります。パターンに一致する既存の値のみが更新または設定解除されます。パターンと「一致しない」行を処理する場合は、前に1つの感嘆符(!)を追加するだけです([EXAMPLES] も参照下さい)が、ただし、これは --fixed-value オプションが使用されていない場合のみ機能することに注意してください。

--type=<type> オプションは git config に指示して、指定の<type>の下で入力値(incoming value)と出力値(outgoing value)が正規化可能であることを確認します。 -type=<type> が指定されていない場合、正規化は実行されません。 呼び出し元は、既に指定済の --type 指定子を --no-type で設定解除できます。

読み取り時、値はデフォルトでシステム、グローバル、リポジトリのローカル構成ファイルから読み取られ、オプション --system--global--local--worktree 、 `--file <filename> ` を使用して、その場所から「のみ」読み取るようにコマンドに指示できます([FILES] 参照)。

書き込み時、新しい値はデフォルトでリポジトリのローカル構成ファイルに書き込まれます。オプション --system--global--worktree--file <filename> ` を使用すれば、コマンドにその場所に書き込むよう指示できます(あなたは `--local と言うこともでき、そしてこれはデフォルトです)。

このコマンドは、エラー時にゼロ以外のステータスで失敗します。 いくつかの終了コードは以下のとおりです:

  • セクションキーが不正(ret=1)

  • セクションまたは名前が与えられてない(ret=2)

  • configファイルが不正(ret=3)

  • configファイルに書き込みできない(ret=4)

  • 存在しないオプションの設定を削除(unseet)しようとしました(ret=5)

  • あなたは、複数の行が一致するオプションを設定(set)/削除(unset)しようとしています(ret=5)

  • 不正な正規表現を使おうとしています(ret=6)

成功の場合、コマンドは終了コード 0 を返します。

使用可能なすべての構成変数のリストは、 git help --config コマンドを使用して取得できます。

OPTIONS

--replace-all

デフォルトの振る舞いでは最大1行を置き換えますが、このオプションより、キー(およびオプションで value-pattern)に一致するすべての行が置換されます。

--add

既存の値を変更せずに、オプションに新しい「行を追加」します。 これは --replace-allvalue-pattern として ^$ を指定しても同じ事が可能です。

--get

指定されたキーの値を取得します(オプションで、値に一致する正規表現でフィルタリングされます)。キーが見つからなかった場合はエラーコード1を返し、複数のキー値が見つかった場合は「最後の値」を返します。

--get-all

--get と同様ですが、複数値キー(複数行;multivar)のすべての値を返します。

--get-regexp

--get-all と同様ですが、名前を正規表現として解釈し、キー名を書き出します。正規表現の照合では現在、大文字と小文字が区別され、セクション名と変数名が小文字になっている正規化されたバージョンのキーに対して実行されますが、サブセクション名は大文字と小文字が区別されません。

--get-urlmatch name URL

2つの部分からなる名前 section.key を指定すると、<url> 部分が指定したURLに最もよく一致する section.<url>.key の値が返されます(そのようなキーが存在しない場合は、 section.keyの値にフォールバックします)。セクションだけを名前として指定した合は、当該セクション内のすべてのキー・値をリストします。値が見つからない場合はエラーコード1を返します。

--global

オプション書き込みの場合: リポジトリの .git/config ではなくグローバル ~/.gitconfig $XDG_CONFIG_HOME/git/config ファイルがある場合は $XDG_CONFIG_HOME/git/config ファイルに書き込みます。

オプション読み取りの場合: 使用可能なすべてのファイルからではなく、グローバル ~/.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/config.worktree が読み書きされる点が異なります。extensions.worktreeConfig が存在しない場合は --local と同じです。

-f config-file
--file config-file

オプション書き込みの場合: リポジトリの .git/config ではなく、指定のファイルに書き込みます。

オプション読み取りの場合: 使用可能なすべてのファイルからではなく、指定のファイルからのみ読み取ります。

[FILES] も参照して下さい。

--blob blob

--file に似ていますが、ファイルの代わりに指定のブロブを使用します。例えば、 master:.gitmodules を使用して、masterブランチのファイル .gitmodules から値を読み取ることができます。ブロブ名の綴りのより完全なリストについては、 gitrevisions(7) の「SPECIFYING REVISIONS」セクションを参照してください。

--remove-section

指定のセクションを構成ファイルから削除します。

--rename-section

指定のセクションの名前を新しい名前に変更します。

--unset

キーに一致する行を構成ファイルから削除します。

--unset-all

キーに一致するすべての行を構成ファイルから削除します。

-l
--list

構成ファイルに「設定されている」すべての変数とその値を一覧表示します(訳注:使用可能なすべての構成変数のリストは、 git help --config)。

--fixed-value

value-pattern 引数と一緒に使用する場合、 value-pattern を正規表現ではなく単なる文字列として扱います。これにより、値が value-pattern と完全に等しいものにのみ一致する、名前/値のペアだけに制限されます。

--type <type>

git config は、入力または出力が指定された型(type)の制約の下で有効であることを保証し、その型の正規形式で出力値を正規化します。

有効な型には以下のものがあります:

  • bool: 値を「true」または「false」として正規化します。

  • int 値を単純な10進数として正規化します。オプションのサフィックス「k」また「m」または「g」を使用すると、入力時に値にそれぞれ1,024または1,048,576(10242)または1,073,741,824(10243)が掛け算されます。

  • bool-or-int: 上記のように、 bool または int のいずれかに従って正規化します。

  • path: $HOME の値を意味する ~ を先頭に追加し、指定のユーザのホームディレクトリを ~user として正規化します。この ~ は値を書き込むときには効果がありません(ただし、あなたはコマンドラインから git config section.variable ~/ と実行してシェルに展開をさせることができます)。

  • expiry-date: 固定または相対の日付文字列からタイムスタンプに変換することで正規化します。この指定は値を書き込むときには効果がありません。

  • color: 値を取得するときに、ANSIカラーエスケープシーケンスに変換して正規化します。値を設定するとき、指定された値がANSIカラーとして正規化可能であることを確認するために健全性チェックが実行されますが、正規化自体は行われず、そのまま書き込まれます。

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

タイプ指定子を選択するための歴史的オプション。 代わりに --type を優先します(上記参照)。

--no-type

(これ以前に設定されていた場合、)これ以前に設定された型指定子の設定を解除します。このオプションは、「git config」が取得した変数を正規化しないように要求します。 --no-type は、--type=<type> または --<type> が無い場合は何の効果もありません。

-z
--null

値やキーを出力するすべてのオプションで、値を(改行ではなく)常にヌルバイト(\0)で終了します。代わりに、キーと値の間の区切り文字として改行を使用します。これにより、例えば、改行を含む値を混乱することなく、出力を安全にパースできます。

--name-only

--list または --get-regexp の構成変数で名前のみを出力します。

--show-origin

照会されたすべての構成オプションの出力に、その構成オプションの出処の種類(ファイル、標準入力、blob、コマンドライン)と実際の出処(設定ファイルのパス、参照、または該当する場合はblobのID)を追加します。

--show-scope

--show-origin と同様に、クエリされたすべての設定オプションの出力をその値のスコープ(ローカル、グローバル、システム、コマンド)で拡張します。

--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 を使用します。

--get-color name [default]

name (例: color.diff.new) に設定されている色を見つけて、ANSIカラーエスケープシーケンスとして標準出力に出力します。 name に色が設定されていない場合は、オプションの default パラメータが代わりに使用されます。

--type=color [--default=<default>]--get-color よりも優先されます(ただし、 --get-color は、 --type=color によって出力される末尾の改行を省略します)。

-e
--edit

指定の構成ファイルを変更するためのエディタを開きます。指定できるのは、 --system または --global または「リポジトリ」(指定なし;デフォルト)、のいずれかです。

--[no-]includes

値を検索するときは、設定ファイルの include.* ディレクティブを尊重します。特定のファイルが指定されている場合(たとえば、 --file--global などを使用した場合)はデフォルトで off になり、すべての構成ファイルを検索する場合は on になります。

--default <value>

--get を使用していて、要求した変数が見つからない場合、 <value> がその変数に割り当てられた値であるかのように動作します。

CONFIGURATION

pager.config は、構成を一覧表示する場合、つまり、 ` --list` 、または複数の結果を返す可能性のある --get-* のいずれか、を使用する場合にのみ尊重されます。デフォルトでは pager を使用します。

FILES

--file で明示的に設定されていない場合、 git config が構成オプションを検索する以下の4つのファイルがあります:

$(prefix)/etc/gitconfig

システム全体(PC毎)の構成ファイル

$XDG_CONFIG_HOME/git/config

2番目のユーザー固有の構成ファイルです。 $XDG_CONFIG_HOME が設定されていないか空の場合 $HOME/.config/git/config が使用されます。このファイルに設定されている単一値の変数は、 ~/.gitconfig にあるものによって上書きされます。このファイルのサポートはごく最近追加されたため、古いバージョンのGitを使用することがある場合は、このファイルを作成しないことをお勧めします。

~/.gitconfig

ユーザー毎の構成ファイル。グローバル(global)構成ファイルとも呼ばれる。

$GIT_DIR/config

リポジトリ毎の構成ファイル。

$GIT_DIR/config.worktree

これはオプションであり、 extensions.worktreeConfig が $GIT_DIR/config に存在する場合にのみ検索されます。

それ以上のオプションが指定されていない場合、すべての読み取りオプションは、使用可能なこれらのファイルをすべて読み取ります。グローバルまたはシステム全体の構成ファイルが使用できない場合、それらは無視されます。リポジトリ設定ファイルが利用できないか読み取り可能でない場合、「git config」はゼロ以外のエラーコードで終了します。 ただし、どちらの場合もエラーメッセージは発行されません。

ファイルは上記の順序で読み取られ、「最後」に見つかった値が前に読み取った値よりも優先されます。なお、複数値(multiple values)を取得すると、すべてのファイルのキーのすべての値が使用されます。

あなたは gitコマンドを実行するとき、 -c オプションを使用して、個々の構成パラメーターをオーバーライドできます。詳細については git(1) を参照してください。

すべての書き込みオプションは、デフォルトではリポジトリ固有の構成ファイルに書き込みます。これは、 --replace-all--unset などのオプションにも影響することに注意してください。 ※ git config は一度に1つのファイルのみを変更します。

これらのルールは、 --global と` --system` と --local と` --worktree` と --file コマンドラインオプションを使用してオーバーライドできます。上記の [OPTIONS] を参照してください。

ENVIRONMENT

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM

グローバルまたはシステムレベルの構成からではなく、指定されたファイルから構成を取得します。詳細については git(1) を参照してください。

GIT_CONFIG_NOSYSTEM

システム全体(PC毎)の $(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と同じように扱われます。つまり、ペアは処理されません。これらの環境変数は構成ファイルの値をオーバーライドしますが、 git -c を介して渡された明示的なオプションによってオーバーライドされます。

これは、共通の構成で複数のgitコマンドを生成したいが、スクリプトを作成する場合など、構成ファイルに依存できない場合に役立ちます。

GIT_CONFIG

git config--file オプションが指定されていない場合は、 --file を介して提供されているかのように GIT_CONFIG によって指定されたファイルを使用します。この変数は他のGitコマンドには影響せず、主に歴史的な互換性のためのものです。 通常、 --file オプションの代わりに使用する理由はありません。

EXAMPLES

以下の .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 core.filemode true

とある架空のプロキシコマンドエントリで、末尾が kernel.org である行を、 "ssh" for kernel.org に置換するには

% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'

これにより、kernel.orgのキーと値のペアのみが置き換えられます。

renamesのエントリを削除するには

% git config --unset diff.renames

マルチ変数(multivar)(上記のcore.gitproxyなど)のエントリを削除する場合は、正確に1行の値に一致する正規表現を指定する必要があります。

特定のキーの値を照会するには、次のようにします。

% git config --get core.filemode

または

% git config core.filemode

また、マルチ変数(multivar)の照会は:

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

マルチ変数のすべての値を知りたい場合は、次のようにします:

% git config --get-all core.gitproxy

あなたが危険極まりない人生を送りたい場合は、以下のようにして core.gitproxy の「全て」を新しいものに置き換えることができます。

% git config --replace-all core.gitproxy ssh

しかし、あなたが本当にデフォルトプロキシの行、つまり「for …」の接尾辞のない行だけを置き換えたい場合は、次のようにします:

% git config core.gitproxy ssh '! for '

感嘆符(!)と実際に一致させるには、以下のことを行う必要があります。

% git config section.key value '[!]'

既存のプロキシを変更せずに新しいプロキシを追加するには、以下を使用します。

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

あなたのスクリプトで構成からカスタマイズされた色を使う例:

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

URL が https://weak.example.com の場合、 http.sslVerify はfalseに設定され、他のすべてのURLでは true に設定されます:

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

CONFIGURATION FILE

Git構成ファイルには、Gitコマンドの動作に影響を与えるいくつかの変数が含まれています。各リポジトリ内のファイル .git/config と、オプションで config.worktree (git-worktree(1) の「CONFIGURATION FILE」セクションを参照)は、そのリポジトリの設定を保存するために使用され、 $HOME/.gitconfig は、ユーザーごとの構成を .git/config ファイルのフォールバック値として保存するために使用されます。 ファイル /etc/gitconfig を使用して、システム全体のデフォルト設定を保存できます。

構成変数は、Git配管コマンドとGit磁器コマンドの両方で使用されます。変数はセクションに分割されます。変数自体の完全修飾変数名は最後のドット区切りセグメントであり、セクション名は最後のドットより前のすべてです。変数名では大文字と小文字が区別されず、英数字(alphanumeric)と -(\x2d) のみが許可され、英字(alphabetic)で始まる必要があります。一部の変数は複数回現れる場合があり、その変数はmultivalueであると言います(訳注:multiple lines(複数行)という表現とmultivalueと言う表現が混在する。configでは同じ意味)。

Syntax

構文はかなり柔軟で寛容です。空白(whitespace)はほとんど無視されます。 #; 文字はそこからその行の行末までコメントにします。空白行は無視されます。

このファイルは、セクションと変数で構成されています。セクションは角括弧内([' … `]')のセクションの名前で始まり、次のセクションが始まるまで続きます。セクション名では大文字と小文字は区別されません。セクション名には、英数字(alphanumeric) と `- (\x2d) と . (\x2e) のみを使用できます。各変数はあるセクションに属している必要があります。つまり、変数の最初の設定の前にセクションヘッダーが必要です。

セクションはさらにサブセクションに分割できます。サブセクションを開始するには、以下の例のように、セクションヘッダーで、セクション名からスペースで区切って、その名前を二重引用符で囲みます:

        [section "subsection"]

サブセクション名では大文字と小文字が区別され、改行とヌルバイト(\x00)以外の任意の文字を含めることができます。 二重引用符 " (\x22)と バックスラッシュ(\x5c;日本の環境では円記号で表示される事がある)は、それぞれ \"\\ としてエスケープすることで含めることができます。 他の文字の前にあるバックスラッシュは、読み取るときに削除されます。 たとえば、 \tt として読み取られ、 \00 として読み取られます。セクションヘッダーは複数行にまたがることはできません。変数は、セクションまたは特定のサブセクションに直接属する場合があります。 [section" subsection "] がある場合は [section] も使用できますが、必須ではありません。

非推奨の [section.subsection] 構文があります。この構文では、サブセクション名は小文字に変換され、大文字と小文字が区別されて比較されます。これらのサブセクション名は、セクション名と同じ制限に従います。

他のすべての行(およびセクションヘッダーの後の行の残りの部分)は、「name = value」(または単に「name」)の形式で設定変数として認識されます(「name」形式は「name = true」の省略形で、変数をブール値「true」に設定します)。変数名では大文字と小文字が区別されず、英数字(alphanumeric)と - (\x2d) のみが許可され、英字(alphabetic)で始まる必要があります。

値を定義する行は、 \ (\x5c) で終了することにより、次の行に続けることができます。続けた時、バックスラッシュと行末は削除されて認識されます。 name = の後の先頭の空白と、その行で最初に現れるコメント文字 # または ; 以降行末まで、または、行末尾の空白は、二重引用符で囲まれていない限り破棄されます。値内の内部空白はそのまま保持されます。

ダブルクォートで囲まれた中では、ダブルクォート " とバックスラッシュ \ 文字はエスケープしなければなりません。 " を表わすには \" を使い、 \ を表わすには \\ を使ってください。

( \"\\ に加えて)認識されるエスケープシーケンスは、改行文字(NL;newline)が \n 、水平タブ(HT;TAB)が \t 、バックスペース(BS)が \b です。他のエスケープシーケンス(8進エスケープシーケンスを含む)は無効です。

Includes

include セクションと includeIf セクションを使用すると、別のソースからの設定ディレクティブを含めることができます。これら2つのセクションは、条件がtrueと評価されない場合 includeIf セクションが無視されることを除いて、同様に動作します。 以下の「Conditional includes」を参照してください。

特別な include.path (または includeIf.*.path )変数をインクルードするファイルの名前に設定することにより、別の構成ファイルをインクルードできます。 変数はその値としてパス名を取り、チルダ展開の対象となります。これらの変数は複数回指定できます。

インクルードファイルの内容は、includeディレクティブの場所で見つかったかのように、すぐに挿入されます。変数の値が相対パスである場合、そのパスは、includeディレクティブが見つかった構成ファイルからの相対パスであると見なされます。例については、以下を参照してください。

Conditional includes

includeIf.<condition>.path 変数をインクルードするファイルの名前に設定することにより、条件付きで別の構成ファイルをインクルードできます。

条件は、キーワードで始まり、その後にコロンと、形式と意味がキーワードによって異なるいくつかのデータが続きます。サポートされているキーワードは以下のとおりです:

gitdir

キーワード gitdir: 続くデータは、グロブパターンとして使用されます。 .git ディレクトリの場所がパターンと一致する場合、インクルード条件が満たされます。

.git の場所は自動検出されるか、 $GIT_DIR 環境変数から取得されます。 リポジトリが .git ファイルを介して(つまり、サブモジュールやリンクされたワークツリーなどから)自動検出される場合、最終的に検出される .git の場所とは、 .git ファイルの場所ではなく .git ファイルからたどった .gitディレクトリの場所です。

パターンには、標準のグロブワイルドカードと、複数のパス部分に一致する可能性のある2つの追加のワイルドカード **//** を含めることができます。詳細については、 gitignore(5) を参照してください。便宜上、以下の記法が使えます:

  • パターンが ~/ で始まる場合、 ~ は環境変数 HOME の内容に置き換えられます。

  • パターンが ./ で始まる場合、現在の設定ファイルを含むディレクトリに置き換えられます。

  • パターンが ~/.// のいずれでも始まらない場合、 **/ 自動的に先頭に追加されます。たとえば、パターン foo/bar**/foo/bar になり、 /any/path/to/foo/bar と一致します。

  • パターンが / で終わる場合、 ** が自動的に追加されます。 たとえば、パターン foo/foo/** になります。言い換えると、「foo」ディレクトリとその中のすべてに再帰的に一致します。

gitdir/i

これは、照合が大文字と小文字を区別せずに行われることを除いて、 gitdir と同じです(大文字と小文字を区別しないファイルシステムなど)。

onbranch

キーワード onbranch: に続くデータは、標準のグロブワイルドカードと、複数のパス部分に一致する可能性のある2つの追加のワイルドカード **//** を含むパターンと見なされます。現在チェックアウトされているブランチの名前がパターンと一致するワークツリーにいる場合、インクルード条件が満たされます。

パターンが / で終わる場合、 ** が自動的に追加されます。 たとえば、パターン foo/foo/** になります。つまり、 foo/ で始まるすべてのブランチに一致します。これは、ブランチが階層的に編成されていて、その階層内のすべてのブランチに構成を適用する場合に役立ちます。

gitdirgitdir/i を介したマッチングに関するいくつかの注意事項:

  • $GIT_DIR の中のシンボリックリンクは、マッチ前に解決されません。

  • シンボリックリンクバージョンとrealpathバージョンの両方のパスが、 $GIT_DIR の値と照合されます。例えば ~/git/mnt/storage/git へのシンボリックリンクである場合、 gitdir:~/gitgitdir:/mnt/storage/git の両方が一致します。

    これは、Git v2.13.0 でのこの機能の最初のリリースには当てはまりませんでした。これは、realpathバージョンにのみ一致していました。この機能の初期リリースとの互換性を希望する構成では、realpathバージョンのみ、あるいは両方のバージョンを指定する必要があります。

  • 注意: 「../」は特別なものではなく、文字通り一致することに注意してください。これは、あなたが望むものではない可能性があります。

Example

# 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

Values

多くの変数の値は単純な文字列として扱われますが、特定のタイプの値をとる変数があり、それらの綴り方に関する規則があります。

boolean

変数がブール値をとると言われるとき、「true」と「false」の多くの同義語が受け入れられます。なお、これらはすべて大文字と小文字を区別しません。

true

ブール値 true のリテラルは、 yesontrue1`です。 また、値の指定無し( `= <value> 無し) の変数は true と見なされます。

false

ブール値 false リテラルは、 noofffalse0 と 空文字列です。

--type = bool 型指定子を使用して値を正規形に変換する場合、 git config は、値の出力を「true」または「false」(小文字で表記)にします。

integer

さまざまなサイズを指定する多くの変数の値には、「k」、「M」などの接尾辞を付けることができます。これは、「数値に1024掛けた値に」、「数値に1024x1024を掛けた値に」などを意味します。

color

色をとる変数の値は、スペースで区切られた色(最大で2つ、1つは前景用(foreground)、もう1つは背景用(background))と、(必要な数の)属性(attribute)の「リスト」です。

使用できる基本色は、 normalblackredgreenyellowbluemagentacyanwhite です。与えられた最初の色は前景用です。2番目は背景用です。 normal を除くすべての基本色には、 brightred のように色の前に bright と付けることで指定できる明るいバリエーションがあります。

色は0から255までの数字で指定することもできます。これらはANSI256色モードを使用します(ただし、すべての端末がこれをサポートしているわけではないことに注意してください)。端末が24ビットRGB値をサポートしている場合は #ff0ab3 のように16進数として指定することもできます。

受け入れられる属性(attribute)は、 bolddimulblinkreverseitalicstrike (取り消し線(cross-out)または「取り消し線」の文字(strikethrough letters)の場合) です。色に関する属性の位置(前、後、または中間)は重要ではありません。特定の属性は、それらの前に「no」または「no-」を付けることによってオフにすることができます(たとえば、「noreverse」、「no-ul」など)。

空のカラー文字列は、色の効果をまったく生成しません。 これは、色を完全に無効にすることなく、特定の要素の色付けを回避するために使用できます。

gitで事前定義されたカラースロットの場合、属性は、カラー出力の各アイテムの先頭でリセットされることを意図しています。したがって、 color.decorate.branch`を black`に設定すると、同じ出力行の前のものが bold または他の属性でペイントされるように設定されている場合(たとえば log --decorate 出力のブランチ名のリストの前で括弧を開く)でも、そのブランチ名がプレーンな black でペイントされます。ただし、カスタムログ形式では、より複雑で階層化された色付けが行われる場合があり、否定された形式が役立つ場合があります。

pathname

パス名の値をとる変数には、 ~/ または ~user/ で始まる文字列を指定できます。このような文字列には、通常のチルダ展開が行われます。 ~/$HOME の値に展開され、 ~user/ は指定のユーザーのホームディレクトリに展開されます。

パスが %(prefix)/ で始まる場合、残りはGitの「ランタイムプレフィックス」に関連するパス、つまりGit自体がインストールされた場所に関連するパスとして解釈されます。 たとえば、 %(prefix)/bin/ は、Git実行可能ファイル自体が存在するディレクトリを指します。Gitがランタイムプレフィックスのサポートなしでコンパイルされた場合、代わりにコンパイルされたプレフィックスが置き換えられます。万が一、展開してはならないリテラルパスを指定する必要がある場合は、 ./%(prefix)/bin のように接頭辞 ./ を付ける必要があります。

Variables

注意: このリストは包括的ではなく、必ずしも完全ではないことに注意してください。コマンド固有の変数については、適切なマニュアルページに詳細な説明があります。

他のgit関連ツールは、独自の変数を使用する場合があります。独自のツールで使用する新しい変数を考案するときは、それらの名前がGit自体や他の一般的なツールで使用されているものと競合しないことを確認し、ドキュメントに記述してください。

advice.*

これらの変数は、新しいユーザーを支援するために設計されたさまざまなオプションのヘルプメッセージを制御します。すべての「advice.*」変数はデフォルトで「true」に設定されており、これらを「false」に設定することで、ヘルプが不要であることをGitに伝えることができます。

fetchShowForcedUpdates

git-fetch(1)がrefの更新後に強制更新を計算したり、 チェックが無効になっていることを警告したりするのに 長い時間がかかる場合に表示されるアドバイス。

pushUpdateRejected

pushNonFFCurrentpushNonFFMatchingpushAlreadyExistspushFetchFirstpushNeedsForcepushRefNeedsUpdate を 同時に無効にする場合は、この変数を false に設定します。

pushNonFFCurrent

現在のブランチへの non-fast-forward 更新が原因で git-push(1) が失敗した場合に表示されるアドバイス。

pushNonFFMatching

git-push(1) を実行し、 「matching refs」を明示的にプッシュ(つまり あなたは「:」を使用したか、 あなたの現在のブランチではないrefspecを指定した)して、 「non-fast-forward」エラーが発生したときに表示されるアドバイスです。

pushAlreadyExists

git-push(1) が、 fast-forwarding の対象とならない更新(タグなど)を拒否した場合に表示されます。

pushFetchFirst

git-push(1) が、私たちが持っていないオブジェクトを指す リモート参照を上書きしようとする更新を 拒否した場合に表示されます。

pushNeedsForce

git-push(1) が、 コミットっぽくないオブジェクトを指すリモートrefを上書きしようとする更新、 またはコミットっぽくないブジェクトを指すリモートrefを作成しようとする更新を 拒否した場合に表示されます。

pushUnqualifiedRefname

git-push(1) が、 ソースと宛先のrefsに基づいて、 ソースが属するリモートref名前空間を推測しようとするのをあきらめたときに表示されます。 ただし、 ソースオブジェクトのタイプに基づいて、 refs/heads/* または refs/tags/* のいずれかにプッシュすることを提案できる場合もあります。

pushRefNeedsUpdate

git-push(1) が、 リモート追跡refにローカルにない更新がある場合に、 ブランチの強制更新を拒否した場合に表示されます。

skippedCherryPicks

git-rebase(1) が、 アップストリームブランチにすでにチェリーピックされているコミットをスキップした場合に表示されます。

statusAheadBehind

git-status(1) が、 リモート追跡refと比較したローカルrefの先行(ahead)/遅延(behind)カウントを計算し、 その計算に予想よりも時間がかかる場合に表示されます。 status.aheadBehind がfalseの場合、 またはオプション --no-ahead-behind が指定されている場合は表示されません。

statusHints

git-status(1) の出力や、 git-commit(1) の コミットメッセージ記入時のテンプレート表示や、 git-switch(1) または git-checkout(1) の ブランチ切り替え時のヘルプメッセージに、 現在の状態からどのように進めていくかの指示を表示します。

statusUoption

コマンドが、 追跡されていないファイルを列挙するのに2秒以上かかる場合は、 git-status(1)-u オプション使用の検討をアドバイスします。

commitBeforeMerge

git-merge(1) がローカルの変更を上書きしないようにマージを拒否した場合に、 アドバイスが表示されます。

resetQuiet

コマンドがreset後に、 ステージングされていない変更を列挙するのに2秒以上かかる場合は、 git-reset(1)--quiet オプション使用の検討をアドバイスします。

resolveConflict

競合が原因で操作が実行できない場合に、 さまざまなコマンドによって表示されるアドバイス。

sequencerInUse

シーケンサーコマンドがすでに進行中の場合に表示されるアドバイス。

implicitIdentity

システムのユーザー名とドメイン名から 情報が推測される場合のID構成の設定方法に 関するアドバイス。

detachedHead

git-switch(1) または git-checkout(1) を使用して HEADのデタッチ状態に移行し、 事後にローカルブランチを作成する方法を 指示したときに表示されるアドバイス。

checkoutAmbiguousRemoteBranchName

git-checkout(1)git-switch(1) の引数が、 明確な引数によらず リモート追跡ブランチがチェックアウトされる状況で、 複数のリモート上のリモート追跡ブランチに対して あいまいに解決される場合に表示されるアドバイス。 このアドバイスが出力される状況で、 特定のリモートをデフォルトで 使用するように設定する方法については、 checkout.defaultRemote 構成変数を参照してください。

amWorkDir

git-am(1) がパッチファイルの適用に失敗した場合に パッチファイルの場所を示すアドバイス。

rmHints

git-rm(1) の出力に失敗した場合、 現在の状態からどのように進めるかについての指示を表示します。

addEmbeddedRepo

誤って、あるgitリポジトリを別のリポジトリ内に追加した 場合の対処方法に関するアドバイス。

ignoredHook

フックが実行可能ファイルとして設定されていないために フックが無視された場合に表示されるアドバイス。

waitingForEditor

Gitがユーザーからのエディタ入力を待機しているときは、 いつでも端末にメッセージを出力します。

nestedTag

ユーザーがタグオブジェクトに再帰的にタグを付けようとした 場合に表示されるアドバイス。

submoduleAlternateErrorStrategyDie

「die」に設定された submodule.alternateErrorStrategy オプションが 致命的なエラーを引き起こす場合に表示されるアドバイス。

addIgnoredFile

ユーザーが、無視されたファイルをインデックスに追加しようとした 場合に表示されるアドバイス。

addEmptyPathspec

ユーザーがpathspecパラメーターを指定せずに addコマンドを実行した場合に表示されるアドバイス。

updateSparsePath

git-add(1) または git-rm(1) のいずれかが、 現在のスパースチェックアウト外のインデックスエントリを 更新するように求められたときに表示されるアドバイス。

core.fileMode

作業ツリー内のファイルの実行可能ビットを尊重するかどうかをGitに通知します。

一部のファイルシステムでは、実行可能としてマークされたファイルがチェックアウトされるか、実行可能ビットがオンになっている実行不可能なファイルをチェックアウトすると、実行可能ビットを失います。 git-clone(1) または git-init(1) は、ファイルシステムを調査して、実行可能ビットを正しく処理し、この変数が必要に応じて自動的に設定されるかどうかを確認します。

リポジトリはファイルモードを正しく処理するファイルシステム上にある可能性があり、この変数は作成時に「true」に設定されますが、後でファイルモードを失う別の環境からアクセスできるようになる可能性があります(たとえば、CIFSマウントを介したext4のエクスポート。CygwinがGit for WindowsまたはEclipseでリポジトリを作成た時など)。このような場合、この変数を「false」に設定する必要がある場合があります。 git-update-index(1) を参照してください。

(設定ファイルでcore.filemodeが指定されていない場合、)デフォルトはtrueです。

core.hideDotFiles

(Windowsのみ)trueの場合、名前がドットで始まる、新しく作成されたディレクトリと新しく作成されたファイルを非表示としてマークします。 dotGitOnly の場合、 .git/ ディレクトリのみが非表示になり、ドットで始まる他のファイルは非表示になりません。デフォルトのモードは「dotGitOnly」です。

core.ignoreCase

APFS、HFS+、FAT、NTFSなどの大文字と小文字を区別しないファイルシステムでGitをより適切に機能させるためのさまざまな回避策を可能にする内部変数。たとえば、Gitが「Makefile」を予期しているときにディレクトリリストで「makefile」が見つかった場合、Git それは実際には同じファイルであると想定し、「Makefile」として記憶し続けます。

デフォルトはfalseですが、 git-clone(1) または git-init(1) は、リポジトリの作成時に必要に応じてcore.ignoreCaseを調査してtrueに設定します。

あなたのオペレーティングシステムとファイルシステムに関して、Gitは、この変数の適切な構成に依存しています。この値を変更すると、予期しない動作が発生する可能性があります。

core.precomposeUnicode

このオプションは、GitのMacOS実装でのみ使用されます。 core.precomposeUnicode=true の場合、GitはMacOSによって行われたファイル名のUnicode分解(unicode decomposition)を元に戻します。これは、MacOSとLinuxまたはWindowsの間でリポジトリを共有する場合に便利です。 (Git for Windows 1.7.10以降、または Git under cygwin 1.7 が必要です)。 falseの場合、ファイル名はGitによって完全に透過的に処理されます。これは、古いバージョンのGitとの下位互換性があります。

core.protectHFS

trueに設定されている場合、 HFS+ ファイルシステムで .git と同等と見なされるパスのチェックアウトを許可しないでください。デフォルトはMacOSでは true 、それ以外の場合は false です。

core.protectNTFS

trueに設定されている場合、NTFSファイルシステムで問題を引き起こす可能性のあるパスのチェックアウトを許可しないでください。 例えば、 8.3 の「短い」名前と競合します。デフォルトは、Windowsでは「true」、それ以外の場合は「false」です。

core.fsmonitor

設定されている場合、この変数の値は、要求された日時以降に変更された可能性のあるすべてのファイルを識別するコマンドとして使用されます。この情報は、変更されていないファイルの不要な処理を回避することにより、gitを高速化するために使用されます。 githooks(5) の「fsmonitor-watchman」セクションを参照してください。

core.fsmonitorHookVersion

fsmonitorを呼び出すときに使用されるフックのバージョンを設定します。現在、バージョン1と2があります。これが設定されていない場合、バージョン2が最初に試行され、失敗した場合はバージョン1が試行されます。 バージョン1は、入力としてtimpstampを使用して、それ以降に変更があったファイルを判別しますが、watchmanなどの一部のモニターでは、timestampを使用すると競合状態になります。バージョン2はopaque stringを使用しているため、モニターは競合状態なしで変更されたファイルを判別するために使用できるものを返すことができます。

core.trustctime

falseの場合、インデックスと作業ツリー間のctimeの違いは無視されます。iノードの変更時刻がGitの外部の何か(ファイルシステムクローラーおよび一部のバックアップシステム)によって定期的に変更される場合に役立ちます。 git-update-index(1) を参照してください。デフォルトではtrueです。

core.splitIndex

trueの場合、インデックスの分割インデックス機能が使用されます。 git-update-index(1) を参照してください。 デフォルトではfalseです。

core.untrackedCache

インデックスの追跡されていないモノのキャッシュ機能をどうするかを決定します。この変数が設定されていない(unset)か、 keep に設定されている場合、キャッシュが保持されます。 true に設定すると、自動的に追加されます。 また、 false に設定すると、自動的に削除されます。 true に設定する前に、mtimeがシステムで正しく機能していることを確認する必要があります。 git-update-index(1) を参照してください。 この設定をデフォルトで true に設定する feature.manyFiles が有効になっていない限り、デフォルトは keep です。

core.checkStat

core.checkStat が設定されていないか default に設定されている場合、Gitがファイルを調べてからファイルが変更されたかどうかを検出するために、stat構造体の多くのフィールドがチェックされます。この構成変数が minimal に設定されている場合、mtimeとctimeの1秒未満の部分、ファイルの所有者のuidとgid、iノード番号(およびGitがそれを使用するようにコンパイルされている場合はデバイス番号も)はチェック対象から除外され、mtimeの2分の1の部分(および core.trustCtime が設定されている場合はctime)とファイルサイズチェックのみがチェック対象として残ります。

(JGitなど)一部のフィールドに使用可能な値を残さないGitの実装があります。これらのフィールドを比較から除外することにより、 minimal モードは、同じリポジトリがこれらの他のシステムによって同時に使用される場合の相互運用性に役立つ可能性があります。

core.quotePath

パスを出力するコマンド(例: ls-filesdiff)は、パス名を二重引用符で囲み("...")、Cが制御文字をエスケープするのと同じ方法でそれらの文字をバックスラッシュ(\)でエスケープすることにより、パス名の「異常な」文字をクォートします(例: TABの場合は \t 、LFの場合は \n 、バックスラッシュの場合は \\ )、または0x80より大きい値のバイト(たとえば、UTF-8の "micro" の場合は8進数 \302\265)。この変数がfalseに設定されている場合、0x80を超えるバイトは「異常」とは見なされなくなります。この変数の設定に関係なく、二重引用符(")、バックスラッシュ(\)、および制御文字は常にエスケープされます。単純なスペース文字は「異常」とは見なされません。多くのコマンドは、 -z オプションを使用してパス名を完全にそのままで出力できます。デフォルト値はtrueです。

core.eol

作業ディレクトリ内で、( text 属性を設定するか、text=auto とGitがコンテンツをテキストとして自動検出することにより)テキストとしてマークされたファイルが使用する行末タイプを設定します。 代替手段は、 lfcrlf と プラットフォームの生来の行末を使用する native があります。デフォルト値は native です。行末変換の詳細については、 gitattributes(5) を参照してください。注意: core.autocrlftrue または input に設定されている場合、この値は無視されることに注意してください。

core.safecrlf

trueの場合、行末変換がアクティブなときに CRLF の変換が可逆的かどうかをGitにチェックさせます。 Gitは、コマンドが作業ツリー内のファイルを直接または間接的に変更するかどうかを確認します。たとえば、あるファイルをコミットしてから同じファイルをチェックアウトすると、作業ツリーに元のファイルが生成されます。この操作が core.autocrlf の現在の設定に当てはまらない場合、Gitはそのファイルを拒否します。変数を warn に設定でき、その場合、Gitは不可逆的な変換についてのみ警告はしますが、操作を続行します。

CRLF変換には、データが破損する可能性がわずかにあります。有効にすると、Gitはコミット時にCRLFをLFに変換し、チェックアウト時にLFをCRLFに変換します。コミット前にLFとCRLFが混在しているファイルは、Gitでは復元できません。リポジトリにLF行末のみが含まれるように行末を修正するのは、テキストファイルの場合は正しい操作です。しかし、誤ってテキストとして分類されたバイナリファイルの場合、変換によってデータが破損する可能性があります。

あなたがこのような破損を早期に認識した場合は、 .gitattributes で変換タイプを明示的に設定することで簡単に修正できます。コミットした直後は、作業ツリーに元のファイルが残っており、このファイルはまだ破損していません。 このファイルはバイナリファイルなのだからと、Gitがファイルを適切に処理することをGitに明示的に伝えることができます。

残念ながら、行末が混在するテキストファイルをクリーンアップするという望ましい効果と、バイナリファイルを破損するという望ましくない効果を区別することはできません。どちらの場合も、CRLFは元に戻せない方法で削除されます。テキストファイルの場合、CRLFは行末であるため、これは正しいことですが、バイナリファイルの場合、CRLFを変換するとデータが破損します。

注意: この安全性チェックは、チェックアウトによって、 core.eolcore.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 属性で使用された場合に Git が UTF-8 のラウンドトリップチェックを行うエンコーディングの、カンマや空白で区切られたリスト(gitattributes(5) を参照)。デフォルト値は SHIFT-JIS です。

core.symlinks

falseの場合、シンボリックリンクは、リンクテキストを含む小さなプレーンファイルとしてチェックアウトされます。 git-update-index(1)git-add(1) は、記録されたタイプを通常のファイルに変更しません。シンボリックリンクをサポートしないFATのようなファイルシステムで役立ちます。

デフォルトは true ですが、git-clone(1)git-init(1) はリポジトリの作成時に core.symlinks を調査して必要に応じて core.symlinks を false に設定します。

core.gitProxy

フェッチにGitプロトコルを使用する場合、リモートサーバーへの直接接続を確立する代わりに(「コマンドホストポート」として)実行する「プロキシコマンド」。変数値が「COMMAND for DOMAIN」形式の場合、コマンドは、指定されたドメイン文字列で終わるホスト名にのみ適用されます。この変数は複数回設定でき、指定された順序で照合されます。最初にマッチしたものが採用されます。

GIT_PROXY_COMMAND 環境変数(特別な「for」処理なしで常に普遍的に適用されます)によってオーバーライドできます。

特別な文字列 none をプロキシコマンドとして使用して、特定のドメインパターンにプロキシを使用しないように指定できます。これは、ファイアウォール内のサーバをプロキシの使用から除外する一方で、外部ドメインには共通のプロキシをデフォルトで使用する場合に便利です。

core.sshCommand

この変数が設定されている場合、 git fetchgit push は、リモートシステムに接続する必要があるときに、 ssh の代わりに指定したコマンドを使用します。このコマンドは GIT_SSH_COMMAND 環境変数と同じ形式であり、環境変数が設定されると上書きされます。

core.ignoreStat

trueの場合、Gitはインデックスと作業ツリーの両方で同じように更新された追跡ファイルの「assume-unchanged」(無変更と仮定する)ビットを設定することにより、ファイルが変更されたかどうかを検出するための lstat() 呼び出しを回避します。

ファイルがGitの外部で変更される場合、ユーザーは変更されたファイルを明示的にステージングする必要があります(たとえば、 git-update-index(1) の「Examples」セクションを参照)。 Gitは通常、これらのファイルへの変更を検出しません。

これは、 CIFS/Microsoft Windows など、 lstat() 呼び出しが非常に遅いシステムで役立ちます。

false がデフォルトです。

core.preferSymlinkRefs

HEADおよびその他のシンボリック参照ファイルのデフォルトの「symref」形式の代わりに、シンボリックリンクを使用します。これは、HEADがシンボリックリンクであることを期待する古いスクリプトを操作するために必要になる場合があります。

core.alternateRefsCommand

alternateから利用可能な履歴のヒントをアドバタイズする場合は、 git-for-each-ref(1) の代わりに、シェルを使用して指定されたコマンドを実行します。最初の引数は、alternateの絶対パスです。出力には、1行に1つの16進オブジェクトIDが含まれている必要があります(つまり、 git for-each-ref --format='%(objectname)' によって生成されたものと同じある必要があります)。

注意: 通常、 あなたは git for-each-ref をconfig値に直接入れることはできません。これは、リポジトリパスを引数として受け取らないためです(ただし、あなたは上記のコマンドをシェルスクリプトでラップすることはできます)。

core.alternateRefsPrefixes

alternateからの参照を一覧表示する場合は、指定のプレフィックスで始まる参照のみを一覧表示します。プレフィックスは 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 = false)、他のすべてのリポジトリはベアであると見なされます(bare = true)。

core.worktree

作業ツリーのルートへのパスを設定します。 GIT_COMMON_DIR 環境変数が設定されている場合、 core.worktree は無視され、作業ツリーのルートを決定するために使用されません。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 サブディレクトリ内の構成ファイル /path/to/.git/config 内の core.worktree が /different/path に設定されていたとする)、これはおそらく設定ミスです。あなたが /path/to ディレクトリでGitコマンドを実行すると、引き続き /different/path が作業ツリーのルートとして使用され、あなたが何をしているのか分かっている(たとえば、リポジトリの通常の作業ツリーとは異なる場所に同じインデックスの読み取り専用スナップショットを作成している)のでない限り混乱を招く可能性があります。

core.logAllRefUpdates

reflogを有効にします。新旧のSHA-1の追加や、日付/時刻・理由の更新による、refである <ref> の更新は、ファイル $GIT_DIR/logs/<ref> が存在する場合のみ、そのファイルにロギングされます。この構成変数が true に設定されている場合、欠落している $GIT_DIR/logs/<ref> ファイルがブランチヘッド(つまり、 refs/heads/ 下)、リモートref(つまり、 refs/ 下)、note refs(つまり、 refs/notes/ 下)、およびシンボリックref HEADalways`に設定されている場合、欠落しているreflogは、 `refs/ 下のすべてのrefに対して自動的に作成されます。

この情報を使用して、「2日前」(2 days ago)にブランチの先端であったコミットを判別できます。

この値は、作業ディレクトリが関連付けられているリポジトリではデフォルトでtrueになり、ベアリポジトリではデフォルトでfalseになります。

core.repositoryFormatVersion

リポジトリの形式とレイアウトのバージョンを識別する内部変数。

core.sharedRepository

group (または true )の場合、リポジトリはグループ内の複数のユーザー間で共有可能になります(すべてのファイルとオブジェクトがグループ書き込み可能であることを確認してください)。 all (または world または everybody)の場合、リポジトリはグループ共有可能であることに加えて、すべてのユーザーが読み取り可能になります。 umask (または false )の場合、Gitは umask(2) によって報告された権限を使用します。「0xxx」(「0xxx」は8進数)の場合、リポジトリ内のファイルはこのモード値になります。「0xxx」はユーザーのumask値をオーバーライドします(他のオプションはユーザーのumask値の要求された部分のみをオーバーライドします)。例:「0660」は、所有者とグループがリポジトリを読み取り/書き込み可能にしますが、他のユーザーはアクセスできません(umaskが「0022」などでない限り、「group」と同等です)。 「0640」は、グループで読み取り可能ですが、グループで書き込み可能ではないリポジトリです。 git-init(1) を参照してください。 デフォルトではFalseです。

core.warnAmbiguousRefs

trueの場合、渡したref名があいまいでリポジトリ内の複数のrefと一致する可能性がある場合、Gitは警告を表示します。 デフォルトではtrue。

core.compression

デフォルトの圧縮レベルを示す整数 -1〜9。 -1はzlibのデフォルトです。0は圧縮がないことを意味し、1〜9はさまざまな速度とサイズのトレードオフであり、9が最も低速です。設定されている場合、これは core.looseCompressionpack.compression などの他の圧縮変数のデフォルトを提供します。

core.looseCompression

整数 -1〜9は、パックファイルにないオブジェクトの圧縮レベルを示します。-1はzlibのデフォルトです。0は圧縮がないことを意味し、1〜9はさまざまな速度とサイズのトレードオフであり、9が最も低速です。設定されていない場合、デフォルトは core.compression です。 これが設定されていない場合、デフォルトは1(最高速度)になります。

core.packedGitWindowSize

1回のマッピング操作でメモリにマップするパックファイルのバイト数。ウィンドウサイズを大きくすると、システムが少数の大きなパックファイルをより迅速に処理できるようになる場合があります。ウィンドウサイズを小さくすると、オペレーティングシステムのメモリマネージャへの呼び出しが増えるため、パフォーマンスに悪影響を及ぼしますが、多数の大きなパックファイルにアクセスする場合のパフォーマンスが向上する可能性があります。

コンパイル時にNO_MMAPが設定されている場合、デフォルトは1Mバイトです。それ以外の場合、32ビットプラットフォームでは32Mバイト、64ビットプラットフォームでは1Gバイトです。これは、すべてのユーザー/オペレーティングシステムにとって妥当なはずです。おそらくあなたはこの値を調整する必要はありません。

k または m または g の一般的な単位接尾辞がサポートされています。

core.packedGitLimit

パックファイルからメモリに同時にマップする最大バイト数。Gitが操作を完了するために一度にこれ以上のバイトにアクセスする必要がある場合、Gitは既存の領域のマップを解除して、プロセス内の仮想アドレス空間を再利用します。

デフォルトは、32ビットプラットフォームでは256Mバイト、64ビットプラットフォームでは32Tバイト(事実上無制限)です。これは、超巨大プロジェクトを除いて、すべてのユーザー/オペレーティングシステムにとって妥当なはずです。あなたは、おそらくこの値を調整する必要はありません。

k または m または g の一般的な単位接尾辞がサポートされています。

core.deltaBaseCacheLimit

複数の削除されたオブジェクトによって参照される可能性のあるベースオブジェクトをキャッシュするために予約するスレッドあたりの最大バイト数。解凍(decompress)されたベースオブジェクト全体をキャッシュに保存することで、Gitは頻繁に使用されるベースオブジェクトを何度もアンパックおよび解凍することを回避できます。

デフォルトは、すべてのプラットフォームで96Mバイトです。これは、超巨大プロジェクトを除いて、すべてのユーザー/オペレーティングシステムにとって妥当なはずです。あなたは、おそらくこの値を調整する必要はありません。

k または m または g の一般的な単位接尾辞がサポートされています。

core.bigFileThreshold

このサイズより大きいファイルは、デルタ圧縮を試行せずに、デフレートして保存されます。デルタ圧縮なしで大きなファイルを保存すると、ディスク使用量が増えるというわずかな犠牲を払って、過度のメモリ使用量を回避できます。加えて、このサイズより大きいファイルは常にバイナリとして扱われます。

デフォルトは、すべてのプラットフォームで512Mバイトです。ソースコードやその他のテキストファイルは依然としてデルタ圧縮できるため、これはほとんどのプロジェクトにとって合理的ですが、より大きなバイナリメディアファイルにとっては合理的ではありません。

k または m または g の一般的な単位接尾辞がサポートされています。

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 環境変数の値にフォールバックするか、それが失敗した場合は、単純なパスワードプロンプトにフォールバックします。外部プログラムには、コマンドライン引数として適切なプロンプトが与えられ、その標準出力にパスワードを書き出す事になっています。

core.attributesFile

.gitattributes (ディレクトリごと) と .git/info/attributes に加えて、Gitはこのファイルで属性を調べます(gitattributes(5) を参照)。パスの拡張は、 core.excludesFile の場合と同じ方法で行われます。デフォルト値は $XDG_CONFIG_HOME/git/attributes です。 $XDG_CONFIG_HOME が設定されていないか空の場合、代わりに $HOME/.config/git/attributes が使用されます。

core.hooksPath

デフォルトでは、Gitは $GIT_DIR/hooks ディレクトリでフックを探します。これを別のパスに設定します。例えば /etc/git/hooks です。そしてGitはそのディレクトリであなたのフックを見つけようとします。例えば $GIT_DIR/hooks/pre-receive の代わりに /etc/git/hooks/pre-receive です。

パスは絶対パスでも相対パスでもかまいません。相対パスは、フックが実行されているディレクトリを基準にしたものと見なされます(githooks(5) の「DESCRIPTION」セクションを参照)。

この設定変数は、あなたのGitフックをリポジトリごとに設定するのではなく一元的に設定したい場合や、デフォルトのフックを変更した init.templateDir に代わるより柔軟で一元的な設定として有用です。

core.editor

エディタを起動してメッセージを編集できる committag などのコマンドは、この変数が設定されているときにこの変数の値を使用し、環境変数 GIT_EDITOR は設定されていません。 git-var(1) を参照してください。

core.commentChar

メッセージを編集できる committag などのコマンドは、この文字で始まるコメント行を考慮し、エディタから戻った後にそれらを削除します(デフォルトは #)。

auto に設定すると、 git-commit は、既存のコミットメッセージのどの行の先頭文字でもない文字を選択します。

core.filesRefLockTimeout

個々の参照をロックしようとしたときに再試行する時間の長さ(ミリ秒単位)。値0は、まったく再試行しないことを意味します。 -1 は無期限に試すことを意味します。 デフォルトは100です(つまり、100ミリ秒再試行します)。

core.packedRefsTimeout

packed-refs ファイルをロックしようとしたときに再試行する時間の長さ(ミリ秒単位)。値0は、まったく再試行しないことを意味します。-1は無期限に試すことを意味します。デフォルトは1000です(つまり、1秒間再試行します)。

core.pager

Gitコマンドで使用するテキストビューア(「less」など)。値はシェルによって解釈されることを意図しています。 優先順位は、 $GIT_PAGER 環境変数、 core.pager 構成、 $PAGER 、そしてコンパイル時に選択されたデフォルト(通常は less)です。

LESS 環境変数が設定されていない(unset)場合、Gitはそれを FRX に設定(set)します(LESS 環境変数が設定されている場合は、Gitはそれをまったく変更しません)。Gitのデフォルト設定である LESS を選択的にオーバーライドする場合は、 core.pager を、例えば less -S と設定できます。これはGitによってシェルに渡され、Gitは最後のコマンドを LESS=FRX less -S に変換します。環境変数では S オプションを設定しませんが、コマンドラインでは設定し、長い行を切り捨てるように指示します。同様に、 core.pagerless -+F に設定すると、環境変数によって指定された F`オプションがコマンドラインによって非アクティブになり、 `less の「1画面の場合は終了」動作が非アクティブになります。特定のGitコマンドに対していくつかのフラグを特に指定してアクティブにすることができます。たとえば、 pager.blameless -S に設定すると、 git blame でのみページャーで行の切り捨てが有効になります。

同様に、 LV 環境変数が設定されていない場合、Gitはそれを -c に設定します。この設定を上書きするには、 LV を別の値でエクスポートするか、 core.pagerlv +c に設定します。

core.whitespace

注意すべき一般的な空白(whitespace)の問題のコンマ(,)区切りのリスト。 gitd iffcolor.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 は、行末のキャリッジリターンをラインターミネータの一部として扱います。つまり、そのようなキャリッジリターンの前の文字が空白(a whitespace)でない場合、 trailing-space はトリガーされません(デフォルトでは有効になっていません)。

  • tabwidth=<n> は、タブが占める文字数を示します。 これは、 indent-with-non-tab と、 Gitが tab-in-indent エラーを修正する場合に関連します。デフォルトのタブ幅は8です。許可される値は1〜63です。

core.fsyncObjectFiles

このブール値は、オブジェクトファイルを書き込むときに fsync() を有効にします。

これは、データの書き込みを適切に順序付けるファイルシステムでは時間と労力の無駄ですが、ジャーナル処理を使用しないファイルシステム(伝統的なUNIXファイルシステム)や、ファイルの内容ではなくメタデータのみをジャーナル処理するファイルシステム(OS XのHFS+や、data=writeback な Linux ext3)で役立ちます。

core.preloadIndex

git diff などの操作のために並列インデックスプリロードを有効にする

これにより、特にキャッシュセマンティクスが弱く、IOレイテンシが比較的高いNFSなどのファイルシステムで、「git diff」や「git status」などの操作を高速化できます。有効にすると、Gitはファイルシステムデータとのインデックス比較を並行して実行し、重複する入出力を許可します。デフォルトはtrueです。

core.unsetenvvars

Windowsのみ: 他のプロセスを生成する前に設定を解除する必要がある環境変数の名前のコンマ(,)区切りのリスト。Git for Windowsが独自のPerlインタープリターの使用を主張しているという事実を説明するために、デフォルトは PERL5LIB です。

core.restrictinheritedhandles

Windowsのみ: 生成されたプロセスが標準のファイルハンドル( stdinstdoutstderr)のみを継承するか、すべてのハンドルを継承するかをオーバーライドします。 auto または true または false にすることができます。デフォルトは auto で、これはWindows7以降では true を意味し、古いバージョンのWindowsでは false を意味します。

core.createObject

これを link に設定できます。この場合、ハードリンク後のソース削除を、オブジェクトの作成が既存のオブジェクトが上書しないことをチェックするために使用します。

一部のファイルシステム/オペレーティングシステムの組み合わせでは、これは信頼できませんので、この構成設定を rename に設定します。ただし、これにより、既存のオブジェクトファイルが上書きされないようにするチェックが削除されます。

core.notesRef

コミットメッセージを表示するときは、指定されたrefに保存されている note も表示します。refは完全に修飾されている必要があります。指定されたrefが存在しない場合、それはエラーではありませんが、noteを印刷してはならないことを意味します。

この設定のデフォルトは「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 ファイルを使用して、単一のインデックスを使用して複数のパックファイルを追跡します。詳細については git-multi-pack-index(1) を参照してください。デフォルトはtrueです。

core.sparseCheckout

「スパースチェックアウト」(sparse checkout)機能を有効にします。 詳細については、 git-sparse-checkout(1) を参照してください。

core.sparseCheckoutCone

スパースチェックアウト機能の「コーンモード」(cone mode)を有効にします。スパースチェックアウトファイルに含まれるパターンのセットが限られている場合、このモードはパフォーマンスに大きな利点をもたらします。詳細については git-sparse-checkout(1) を参照してください。

core.abbrev

オブジェクト名の省略形の長さを設定します。指定されていないか「auto」に設定されている場合、リポジトリ内のパックされたオブジェクトのおおよその数に基づいて適切な値が計算されます。それは、省略されたオブジェクト名がしばらくの間(some time)一意であるのに十分な長さです。「no」に設定すると、省略形は作成されず、オブジェクト名は完全な長さで表示されます。 最小の長さは4です。

add.ignoreErrors
add.ignore-errors (非推奨)

インデックスエラーのために一部のファイルを追加できない場合にファイルの追加を続行するように git add に指示します。 git-add(1)--ignore-errors オプションと同等です。 add.ignore-errors は、構成変数の通常の命名規則に従わないため、非推奨になりました。

add.interactive.useBuiltin

[EXPERIMENTAL](実験的)Perlスクリプトバージョンの代わりに、対話バージョンの git-add(1) の実験的な組み込み実装を使用するには、 true に設定します。デフォルトでは false です。

alias.*

git(1) コマンドラッパーのコマンドエイリアス。例えば、 alias.last = cat-file commit HEAD 定義後、 git last の呼び出しは git cat-file commit HEAD と同等です。スクリプトの使用に関する混乱や問題を回避するために、既存のGitコマンドを非表示にするエイリアスは無視されます。 引数はスペースで分割され、通常のシェルのクォートとエスケープがサポートされています。 引用符のペアまたはバックスラッシュ(\)を使用して、それらをクォートすることができます。

エイリアスの最初の単語は必ずしもコマンドである必要はないことに注意してください。 これは、git の呼び出しに渡されるコマンドラインオプションにすることができます。 特に、これは、 -c を使用して1回限りの構成で渡す場合、または -p を使用して強制的にページネーションを行う場合に役立ちます。 たとえば、 loud-rebase = -c commit.verbose=true rebase は、git loud-rebase の実行が git -c commit.verbose=true rebase と同等になるように定義できます。 また、 ps = -p status は便利なエイリアスで、 git psgit status の出力をページ分割して出力します。

エイリアス展開の前に感嘆符(!)が付いている場合は、シェルコマンドとして扱われます。 たとえば、 alias.new = !gitk --all --not ORIG_HEAD を定義すると、 git new の呼び出しは、シェルコマンド gitk --all --not ORIG_HEAD を実行するのと同じです。 シェルコマンドは、リポジトリの最上位ディレクトリから実行されることに注意してください。これは、必ずしも現在のディレクトリであるとは限りません。 GIT_PREFIX は、元のカレントディレクトリから git rev-parse --show-prefix を実行したときに返される値が設定されます。 git-rev-parse(1) を参照してください。

am.keepcr

trueの場合、 git-am は、パラメーター --keep-cr を使用してmbox形式のパッチに対して` git-mailsplit` を呼び出します。 この場合、 git-mailsplit\r\n で終わる行から \r を削除しません。 コマンドラインから --no-keep-cr を指定することでオーバーライドできます。 git-am(1)git-mailsplit(1) を参照してください。

am.threeWay

デフォルトでは、パッチが正しく適用されない場合、 git am は失敗します。 trueに設定すると、この設定は、パッチが適用される予定のブロブのIDを記録し、それらのブロブをローカルで使用できる場合に、3方向マージにフォールバックするように git am に指示します(コマンドラインから --3way オプションを指定するのと同じです)。 デフォルトは false です。 git-am(1)を参照してください。

apply.ignoreWhitespace

change に設定すると、 --ignore-space-change オプションと同じように、空白の変更を無視するように git apply に指示します。 no, none, never, false のいずれかに設定すると、すべての空白の違いを尊重するように git apply に指示されます。 git-apply(1) を参照してください。

apply.whitespace

--whitespace オプションと同じ方法で、 git apply に空白の処理方法を指示します。 git-apply(1) を参照してください。

blame.blankBoundary

git-blame(1)で境界コミット(boundary commits)の空白コミットオブジェクト名を表示します。このオプションのデフォルトはfalseです。

blame.coloring

これにより、blame出力に適用される配色が決まります。 これは、 repeatedLines または highlightRecent またはデフォルトの none にすることができます。

blame.date

git-blame(1) で日付を出力するために使用される形式を指定します。 設定を解除すると、iso形式が使用されます。 サポートされている値については、 git-log(1)--date オプションの説明を参照してください。

blame.showEmail

git-blame(1) で、作者名(author)の代わりに作者の電子メールアドレス(author email)を表示します。 このオプションのデフォルトはfalseです。

blame.showRoot

git-blame(1) ではルートコミットを境界として扱わないでください。 このオプションのデフォルトはfalseです。

blame.ignoreRevsFile

git-blame(1) で、ファイルにリストされているリビジョン(1行に1つの省略されていないオブジェクト名)を無視します。 # で始まる空白とコメントは無視されます。 このオプションは複数回繰り返すことができます。 空のファイル名は、無視されたリビジョンのリストをリセットします。 このオプションは、コマンドラインオプション --ignore-revs-file の前に処理されます。

blame.markUnblamableLines

git-blame(1)の出力で * を使用して、別のコミットに帰することができなかった、無視されたリビジョンによって変更された行をマークします。

blame.markIgnoredLines

git-blame(1)の出力で、別のコミットに起因する無視されたリビジョンによって変更された行を ? でマークします。

branch.autoSetupMerge

git-pull(1) が開始点ブランチから適切にマージされるように、 git branchgit switchgit checkout に新しいブランチを設定するように指示します。 このオプションが設定されていない場合でも、この動作は、 --track--no-track オプションを使用してブランチごとに選択できることに注意してください。 有効な設定は次のとおりです: false - 自動セットアップは行われません。 true - 開始点がリモート追跡ブランチの場合、自動セットアップが実行されます。 always - 自動セットアップは、開始点がローカルブランチまたはリモート追跡ブランチのいずれかである場合に実行されます。 このオプションのデフォルトはtrueです。

branch.autoSetupRebase

別のブランチを追跡する git branch または git switch または git checkout を使用して新しいブランチが作成されると、この変数はGitにマージではなくリベースするプルを設定するように指示します(branch.<name>.rebase 参照)。 never の場合、リベースが自動的にtrueに設定されることはありません。 local の場合、他のローカルブランチの追跡されたブランチに対してリベースがtrueに設定されます。 remote の場合、リモート追跡ブランチの追跡されたブランチに対してリベースがtrueに設定されます。 always の場合、リベースはすべての追跡ブランチに対してtrueに設定されます。 別のブランチを追跡するためにブランチを設定する方法の詳細については、 branch.autoSetupMerge を参照してください。 このオプションのデフォルトは never です。

branch.sort

この変数は、 git-branch(1) によって表示されるときのブランチの並べ替え順序を制御します。 --sort=<value> オプションが指定されていない場合、この変数の値がデフォルトとして使用されます。 有効な値については、 git-for-each-ref(1) のfield namesを参照してください。

branch.<name>.remote

ブランチ<name>にいる場合、フェッチ元/プッシュ先 のリモートを git fetchgit push に通知します。 プッシュ先のリモートは、 (全ブランチ用の) remote.pushDefault でオーバーライドできます。 現在のブランチの場合、プッシュ先のリモートは、 branch.<name>.pushRemote によってさらにオーバーライドされる可能性があります。 リモートが構成されていない場合、またはブランチを使用していない場合、デフォルトでは、フェッチについては origin に、プッシュについては remote.pushDefault になります。 さらに、 . (ピリオド)は現在のローカルリポジトリ(ドットリポジトリ)です。下記の branch.<name>.merge の最後の注意を参照してください。

branch.<name>.pushRemote

ブランチ<name>にいる場合、プッシュするための branch.<name>.remote をオーバーライドします。 また、ブランチ<name>からプッシュするための remote.pushDefault をオーバーライドします。 ある場所(あなたのアップストリームなど)から別の場所(独自の公開リポジトリなど)にプッシュする場合は、 remote.pushDefault を設定して、すべてのブランチにプッシュするリモートを指定し、そして、このオプションを使用して 特定のブランチに対してオーバーライドします。

branch.<name>.merge

branch.<name>.remote とともに、指定されたブランチのアップストリームブランチを定義します。 マージするブランチを git fetch/git pull/git rebase に通知し、 git push にも影響を与える可能性があります(push.default参照)。 ブランチ<name>にいる場合、FETCH_HEADでマージするためにマークされるデフォルトのrefspecを git fetch に指示します。 値はrefspecのリモート部分のように処理され、 branch.<name>.remote ` で指定されたリモートからフェッチされたrefと一致する必要があります。 マージ情報は、マージのためにデフォルトのブランチを検索するために `git pull (最初に git fetch を呼び出します)によって使用されます。 このオプションがない場合、 git pull はデフォルトで、フェッチされた最初のrefspecをマージします。 octopusマージを取得するには、複数値を指定します。 あなたがローカルリポジトリ内の別のブランチから<name>にマージされるように git pull を設定したい場合は、branch.<name>.mergeが目的をブランチを指すようにして、そして、 branch.<name>.remote に相対パス設定 . (ピリオド)を使用できます。

branch.<name>.mergeOptions

ブランチ<name>にマージするためのデフォルトオプションを設定します。 構文とサポートされているオプションは git-merge(1) のものと同じですが、空白文字を含むオプション値は現在サポートされていません。

branch.<name>.rebase

trueの場合、 git pull の実行時にデフォルトのリモートからデフォルトのブランチをマージするのではなく、フェッチされたブランチの上にブランチ<name>をリベースします。 ブランチ固有ではない方法でこれを行うには、 pull.rebase を参照してください。

When merges (or just m), pass the --rebase-merges option to git rebase so that the local merge commits are included in the rebase (see git-rebase(1) for details).

preserve (または単に pmerges を優先してこれは非推奨)の場合は、 --preserve-mergesgit rebase に渡して、ローカルでコミットされたマージコミットが git pull を実行してもフラット化されないようにします。

値が interactive (または単に i)の場合、リベースは対話モードで実行されます。

注意: これはおそらく危険な操作です。 あなたが影響を理解していない限り、使用しないでください (詳細については、 git-rebase(1) を参照してください)。

branch.<name>.description

ブランチの説明は、 git branch --edit-description で編集できます。 ブランチの説明は、format-patchのカバーレターまたはrequest-pullの概要に自動的に追加されます。

browser.<tool>.cmd

指定したブラウザ(<tool>)を起動するコマンドを指定してください。 指定されたコマンドは、引数として渡されたURLを使用してシェルで評価されます。 (git-web--browse(1) を参照してください。)

browser.<tool>.path

HTMLヘルプ(git-help(1)-w オプション参照) または gitwebの作業リポジトリ(git-instaweb(1) 参照) をブラウズするために使用される可能性のある指定のツール(<tool>)のパス(path)をオーバーライドします。

checkout.defaultRemote

git checkout <something> または git switch <something> を実行し、リモートが1つしかない場合、 origin/<something> のチェックアウトと追跡に暗黙的にフォールバックする可能性があります。 <something> 参照を持つリモートが複数あるとすぐに動作しなくなります。 この設定により、曖昧性解消に関して常に勝利させる優先リモートの名前を設定できます。 典型的なユースケースは、これを origin に設定することです。

現在、これは git-switch(1)git-checkout(1) によって、git checkout <something>git switch <something> が別のリモート上の <something> ブランチをチェックアウトするときに使われています。また git-worktree(1)git worktree add がリモートブランチを参照しているときに使われています。 この設定は、将来、他のチェックアウトのようなコマンドまたは機能に使用される可能性があります。

checkout.guess

git checkoutgit switch の、 --guess または --no-guess オプションのデフォルト値を提供します。 git-switch(1) および git-checkout(1) を参照してください。

checkout.workers

作業ツリーを更新するときに使用する並列ワーカーの数。デフォルトは1、つまり順次実行です。 1未満の値に設定すると、Gitは使用可能な論理コアの数と同じ数のワーカーを使用します。 この設定と checkout.thresholdForParallelism は、チェックアウトを実行するすべてのコマンドに影響します。 例えば、 checkout, clone, reset, sparse-checkout, などです。

注意: 並列チェックアウトは通常、SSDまたはNFS上にあるリポジトリのパフォーマンスを向上させます。 回転するディスクやコアの数が少ないマシン上のリポジトリの場合、デフォルトのシーケンシャルチェックアウトの方がパフォーマンスが向上することがよくあります。 リポジトリのサイズと圧縮レベルも、並列バージョンのパフォーマンスに影響を与える可能性があります。

checkout.thresholdForParallelism

少数のファイルで並列チェックアウトを実行する場合、サブプロセスの生成とプロセス間通信のコストが並列化のメリットを上回る可能性があります。 この設定により、並列チェックアウトを試行する必要のあるファイルの最小数を定義できます。 デフォルトは100です。

clean.requireForce

-f または -i または -n が指定されない限り、git-clean が何もしないようにするためのブール値です。 デフォルトは true です。

clone.defaultRemoteName

リポジトリのクローンを作成するときに作成するリモートの名前。 デフォルトは origin で、 --origin コマンドラインオプションを git-clone(1) に渡すことでオーバーライドできます。

clone.rejectShallow

リポジトリが浅い(shallow)場合は、リポジトリの複製(clone)を拒否します。コマンドラインでオプション --reject-shallow を渡すことでオーバーライドできます。 git-clone(1) を参照してください

color.advice

ヒントの色を有効/無効にするブール値(たとえば、プッシュが失敗した場合のリストについては advice.* を参照します)。 always または false(または never) または auto(または true) に設定でき、その場合、色は、エラー出力が端末に送信される場合にのみ使用されます。 設定されていない場合は、 color.ui の値が使用されます(デフォルトでは auto )。

color.advice.hint

ヒントにはカスタマイズされた色を使用します。

color.blame.highlightRecent

これは、行の履歴年代(age)に応じて、blame行のメタデータに色を付けるために使用できます。

この設定は、色と日付設定のコンマ区切りリストに設定する必要があります。色で開始および終了し、日付は古いものから新しいものへと設定する必要があります。 指定されたタイムスタンプの前に行が導入された場合、メタデータは指定の色付けされ、古いタイムスタンプの色を上書きします。

絶対タイムスタンプの代わりに、相対タイムスタンプも機能します。例えば、2.weeks.ago は、2週間より古いものに対処するために有効です。

デフォルトは blue,12 month ago,white,1 month ago,red で、1年以上前のすべてを青に色付けし、1か月前から1年前までの変更は白のままにし、先月に導入された行赤に色付けします。

color.blame.repeatedLines

行ごとにメタ情報が繰り返されるgit-blame出力の部分(コミットID、作成者名、日付、タイムゾーンなど)にカスタマイズ色を使用します。デフォルトは 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(その他のref)、のいずれかです。

color.diff

ANSIエスケープシーケンスを使用してパッチに色を追加するかどうか。 これが always に設定されている場合、 git-diff(1)git-log(1)git-show(1) はすべてのパッチに色を使用します。 true または auto に設定されている場合、これらのコマンドは、端末への出力時にのみ色を使用します。 設定されていない場合は、 color.ui の値が使用されます(デフォルトでは auto)。

これは、 git-format-patch(1) または git-diff-{asterisk} 配管コマンドには影響しません。 --color[=<when>] オプションを使用してコマンドラインでオーバーライドできます。

color.diff.<slot>

diffカラー化にカスタマイズ色を使用します。 <slot> は、パッチのどの部分で指定された色を使用するかを指定します。 次のいずれか一つです: context(コンテキストテキスト。 plain は歴史的な同義語です)、 meta(メタ情報)、 frag(ハンクヘッダー)、 func(ハンクヘッダーの関数)、 old(削除された行)、 new(追加された行)、 commit(コミットヘッダー)、 whitespace(空白エラーを強調表示)、 oldMoved(削除された複数行)、 newMoved(追加された複数行)、 oldMovedDimmedoldMovedAlternativeoldMovedAlternativeDimmednewMovedDimmednewMovedAlternativenewMovedAlternativeDimmed(詳細については、 git-diff(1)--color-moved<mode> 設定参照)、 contextDimmedoldDimmednewDimmedcontextBoldoldBoldnewBold(詳細については git-range-diff(1) 参照)。

color.decorate.<slot>

git log --decorate 出力にカスタマイズ色を使用します。 <slot> にはそれぞれ、ローカルブランチ、リモート追跡ブランチ、タグ、stash、HEADと、graftedコミットをあらわす、 branchremoteBranchtagstashHEADgrafted のうちの一つを指定します。

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

一致テキスト(matchContextmatchSelected の設定と同じ)

matchContext

内容行の一致テキスト

matchSelected

選択行の一致テキスト

selected

選択行の非一致テキスト

separator

行内のフィールド間セパレータ(:-=)と、ハンク間セパレータ(--)

color.interactive

always に設定すると、対話プロンプトと表示には常に色を使用します(git-add --interactivegit-clean --interactive`で使用されるものなど)。 false(または `never)の場合、決して色を使用しません。 true または auto に設定すると、出力が端末に向けられている場合にのみ色を使用します。 設定されていない場合は、 color.ui の値が使用されます(デフォルトでは auto)。

color.interactive.<slot>

git add --interactive および git clean --interactive 出力にカスタマイズ色を使用します。 <slot>`は、対話コマンドからの通常の出力の4つの異なるタイプに対して、 `prompt または header または help または error の場合があります。

color.pager

auto カラーモードがページャーに送られる出力を色付けするかどうかを指定するブール値。 デフォルトはtrueです。 ページャーがANSIカラーコードを理解しない場合は、これをfalseに設定します。

color.push

プッシュエラーで色を有効/無効にするブール値。 alwaysfalse(または never)または auto(または true)に設定でき、その場合、色はエラー出力が端末に送られる場合にのみ使用されます。 設定されていない場合は、 color.ui の値が使用されます(デフォルトでは auto)。

color.push.error

プッシュエラーのカスタマイズされた色に使用。

color.remote

設定されている場合、行の先頭にあるキーワードが強調表示されます。 キーワードは errorwarninghintsuccess であり、大文字と小文字を区別せずに照合されます。 always または false(または never)または auto(または true)に設定できます。 設定されていない場合は、 color.ui の値が使用されます(デフォルトでは auto)。

color.remote.<slot>

リモートキーワードごとにカスタマイズ色を使用します。 <slot> は、対応するキーワードに一致する hint または warning または success または error の場合があります。

color.showBranch

linkgit:git-show-branch[1]の出力で色を有効/無効にするブール値。 alwaysfalse(または never)または auto (または true) に設定でき、その場合、色は出力が端末への場合にのみ使用されます。 設定されていない場合は、 color.ui の値が使用されます(デフォルトでは auto)。

color.status

git-status(1) の出力で色を有効/無効にするブール値。 alwaysfalse(または 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

プッシュが拒否されたときに色を有効/無効にするブール値。 alwaysfalse(または never)または auto(または true)に設定でき、その場合、色はエラー出力が端末に送られる場合にのみ使用されます。 設定されていない場合は、 color.ui の値が使用されます(デフォルトでは auto)。

color.transport.rejected

プッシュが拒否された時に使うカスタマイズ色。

color.ui

この変数は、コマンドファミリごとの色の使用を制御する color.diffcolor.grep などの変数のデフォルト値を決定します。 より多くのコマンドが --color オプションのデフォルトを設定するための構成を習得するにつれて、その範囲は拡大します。 他の構成または --color オプションで明示的に有効にしない限り、Gitコマンドで色を使用しないようにする場合は、false または never に設定します。 機械での利用を目的としない、すべての出力でカラーを使用する場合は always に設定し、端末への書き込み時にそのような出力でカラーを使用する場合は true または auto (これはGit 1.8.4以降のデフォルトです)に設定します。

column.ui

サポートされているコマンドを列(column)で出力するかどうかを指定します。 この変数は、スペースまたはコンマで区切られたトークンのリストで構成されます:

以下のオプションは、機能を有効にするタイミングを制御します(デフォルトは never):

always

常に列表示

never

決して列表示しない

auto

端末へ出力の場合は列表示

以下のオプションはレイアウトを制御します(デフォルトは column)。 alwaysneverauto のいずれも指定されていない場合に、以下のいずれかを設定すると、 always の指定を含みます。

column

行の前に列を埋める

row

列の前に行を埋める

plain

1つの列に表示

最後に、以下のオプションはレイアウトオプションと組み合わせることができます(デフォルトは 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

この設定は、 git commit--cleanup オプションのデフォルトを上書きします。 詳細については、 git-commit(1) を参照してください。 デフォルトを変更すると、コメント文字 # で始まる行をログメッセージに常に残しておきたい場合に役立ちます。その場合は、 git config commit.cleanup whitespace を実行します(注意:これを行う場合は、コミットログテンプレートの # で始まるヘルプ行を自分で削除する必要があることに注意してください)。

commit.gpgSign

すべてのコミットをGPG署名する必要があるかどうかを指定するブール値。 リベースなどの操作を行うときにこのオプションを使用すると、多数のコミットが署名される可能性があります。 エージェントを使用して、GPGパスフレーズの入力を省略するようにすると便利な場合があります。

commit.status

エディタを使用してコミットメッセージを準備するときに、コミットメッセージテンプレートにステータス情報を含めることを有効/無効にするブール値。 デフォルトはtrueです。

commit.template

新しいコミットメッセージのテンプレートとして使用するファイルのパス名を指定します。

commit.verbose

git commit でverboseレベルを指定するブール値またはint。 git-commit(1) を参照してください。

commitGraph.generationVersion

commit-graph ファイルの書き込みまたは読み取り時に使用する世代番号バージョン(generation number version)のタイプを指定します。 バージョン 1 が指定されている場合、修正されたコミット日付は書き込まれたり読み取られたりしません。 デフォルトは 2 です。

commitGraph.maxNewFilters

git commit-graph write--max-new-filters オプションのデフォルト値を指定します(git-commit-graph(1) 参照)。

commitGraph.readChangedPaths

trueの場合、gitはcommit-graphファイルで変更パスブルームフィルター(the changed-path Bloom filters)を使用します(存在し、有効な場合)。 デフォルトはtrueです。 詳細については、 git-commit-graph(1) を参照してください。

credential.helper

ユーザー名またはパスワードの資格情報が必要なときに呼び出される外部ヘルパーを指定します。ヘルパーは、ユーザーに資格情報の入力を求めないように、外部ストレージを参照する場合があります。これは通常、可能な引数を持つ資格情報ヘルパーの名前ですが、引数を持つ絶対パス、または ! が前に付いている場合はシェルコマンドの場合もあります。

注意: 複数のヘルパーが定義されている場合があることに注意してください。詳細と例については、 gitcredentials(7) を参照してください。

credential.useHttpPath

資格情報を取得するとき、http URL または https URL のパス部分を重要視します。デフォルトはfalseです。詳細については、 gitcredentials(7) を参照してください。

credential.username

ネットワーク認証にユーザー名が設定されていない場合は、デフォルトでこのユーザー名を使用します。 以下の credential.<context>.* と gitcredentials(7) を参照してください。

credential.<url>.*

上記の credential.* オプションは、一部の資格情報に選択的に適用できます。 たとえば、 "credential.https://example.com.username" は、example.com への https 接続に対してのみデフォルトのユーザー名を設定します。 URLの照合方法の詳細については、 gitcredentials(7) を参照してください。

credentialCache.ignoreSIGHUP

git-credential-cache—daemon に、終了する代わりにSIGHUPを無視するように指示します。

credentialStore.lockTimeoutMS

資格情報ファイルをロックしようとしたときに git-credential-store が再試行する時間の長さ(ミリ秒単位)。値0は、まったく再試行しないことを意味します。-1は無期限に試すことを意味します。デフォルトは1000です(つまり、1秒間再試行します)。

completion.commands

これは、補完コマンドのリストからコマンドを追加または削除するためにgit-completion.bashによってのみ使用されます。通常、磁器コマンドと、いくつかの選択されたコマンドのみが補完します。この変数には、スペースで区切ってコマンドを追加できます。 コマンドの前に - を付けると、既存のリストから削除されます。

diff.autoRefreshIndex

git diff を使用して作業ツリーファイルと比較する場合、統計のみの変更を変更されたものと見なさない。代わりに、サイレントに git update-index --refresh を実行して、ワークツリーの内容がインデックスの内容と一致するパスの、キャッシュされた統計情報を更新します。このオプションのデフォルトはtrueです。注意: これは git diff 磁器コマンドにのみ影響し、 git diff-files などの下位レベルのdiffコマンドには影響しないことに注意してください。

diff.dirstat

git-diff(1) およびその仲間に対する --dirstat オプションのデフォルトの動作を指定する --dirstat パラメーターのコンマ区切りリスト。デフォルトは(--dirstat=<param1,param2,...> を使用して)コマンドラインでオーバーライドできます。フォールバックのデフォルトは changes,noncumulative,3 です(diff.dirstat によって変更されていない限り)。以下のパラメータを使用できます:

changes

ソースから削除された、または宛先に追加された行をカウントして、dirstat数を計算します。これは、ファイル内の純粋なコード移動の量を無視します。つまり、ファイル内の行の再配置は、他の変更ほどカウントされません。これは、パラメーターが指定されていない場合のデフォルトの動作です。

lines

通常の行ベースのdiff分析を実行し、削除/追加 された行数を合計して、dirstat数を計算します。(バイナリファイルの場合、バイナリファイルには行の自然な概念がないため、代わりに64バイトのチャンクをカウントします)。 これは changes 動作よりもコストのかかる --dirstat 動作ですが、他の変更と同じようにファイル内の再配置された行をカウントします。 結果の出力は、他の --*stat オプションから得られるものと一致しています。

files

変更されたファイルの数を数えて、dirstat数を計算します。変更された各ファイルは、dirstat分析で等しくカウントされます。これは、ファイルの内容をまったく調べる必要がないため、計算コストが最も安価な --dirstat の動作です。

cumulative

親ディレクトリの子ディレクトリの変更もカウントします。 cumulative を使用する場合、報告されるパーセンテージの合計が100%を超える場合があることに注意してください。 デフォルトの(非累積的な)動作は、 non-cumulative パラメーターで指定できます。

<limit>

整数パラメーターは、カットオフパーセント(デフォルトでは3%)を指定します。変更への貢献がこの割合より少ないディレクトリは出力に表示されません。

例: 変更されたファイルの総数の10%未満のディレクトリを無視し、親ディレクトリに子ディレクトリの数を累積しながら、変更されたファイルをカウントする: files,10,cumulative

diff.statGraphWidth

--stat 出力でグラフ部分の幅を制限します。設定されている場合、format-patchを除く --stat 出力を生成するすべてのコマンドに適用されます。

diff.context

デフォルトの3ではなく<n>行のコンテキストで差分を生成します。この値は -U オプションによってオーバーライドされます。

diff.interHunkContext

指定された行数までのdiffハンク間のコンテキストを表示し、それによって互いに近いハンクを融合します。この値は、 --inter-hunk-context コマンドラインオプションのデフォルトとして機能します。

diff.external

この構成変数が設定されている場合、diffの生成は、内部のdiff機構を使用して実行されるのではなく、指定されたコマンドを使用して実行されます。 ‘GIT_EXTERNAL_DIFF’ 環境変数でオーバーライドできます。このコマンドは、 git(1) の「git Diffs」で説明されているパラメーターを使用して呼び出されます。 注意: ファイルのサブセットでのみ外部diffプログラムを使用する場合は、代わりに gitattributes(5) を使用することをお勧めします。

diff.ignoreSubmodules

--ignore-submodules のデフォルト値を設定します。これは git diff 磁器コマンドにのみ影響し、 git diff-files などの下位レベルのdiffコマンドには影響しないことに注意してください。 git checkoutgit switch も、コミットされていない変更を報告するときにこの設定を尊重します。 all に設定すると、 --ignore-submodules コマンドラインオプションを使用してオーバーライドされない限り、 status.submoduleSummary が設定されている場合、通常は git commit および git status で表示されるサブモジュールの概要が無効になります。 git submodule コマンドは、この設定の影響を受けません。デフォルトでは、これは untracked に設定されているため、追跡されていないサブモジュールはすべて無視されます。

diff.mnemonicPrefix

設定されている場合、 git diff は、比較対象に応じて標準の a/b/ とは異なるプレフィックスのペアを使用します。この構成が有効な場合、逆差分出力でもプレフィックスの順序が入れ替わります:

git diff

(i)ndex と (w)ork tree を比較

git diff HEAD

(c)ommit と (w)ork tree を比較

git diff --cached

(c)ommit と (i)ndex を比較

git diff HEAD:file1 file2

(o)bject と (w)ork tree エンティティを比較

git diff --no-index a b

2つの非git項目 (1) と (2) を比較

diff.noprefix

設定されている場合、 git diff は送信元または宛先のプレフィックスを表示しません。

diff.relative

true に設定すると、 git diff はディレクトリ外の変更を表示せず、現在のディレクトリへの相対的なパス名を表示します。

diff.orderFile

diff内でファイルを並べ替える方法を示すファイル。 詳細については、 git-diff(1)-O オプションを参照してください。 diff.orderFile が相対パス名の場合、作業ツリーの最上位を基準として扱います。

diff.renameLimit

コピー/名前変更 の検出の徹底的な部分で考慮するファイルの数。 git diff-l オプションと同等です。設定されていない場合、デフォルト値は現在1000です。この設定は、名前変更の検出がオフになっている場合は効果がありません。

diff.renames

Gitが名前の変更を検出するかどうかとその方法。 "false" に設定すると、名前変更の検出が無効になります。 "true" に設定すると、基本的な名前変更の検出が有効になります。 "copies" または "copy" に設定されている場合、Gitはコピーも検出します。デフォルトはtrueです。これは git-diff(1)git-log(1) のような git diff 磁器コマンドにのみ影響し、 git-diff-files(1) などの下位レベルのコマンドには影響しないことに注意してください。

diff.suppressBlankEmpty

空の出力行の前にスペースを印刷する標準的な動作を禁止するブール値。デフォルトはfalseです。

diff.submodule

サブモジュールの違いを表示する形式を指定します。 "short" 形式は、範囲の最初と最後にコミットの名前を表示するだけです。 "log" 形式は、 git-submodule(1)summary のように範囲内のコミットをリストします。 "diff" 形式は、サブモジュールの変更された内容のインラインdiffを示します。デフォルトは "short" です。

diff.wordRegex

単語ごとの差の計算を実行するときに「単語」(word)とは何かを判別するために使用されるPOSIX拡張正規表現。正規表現に一致する文字シーケンスは「単語」(words)であり、他のすべての文字は*無視できる*空白(whitespace)です。

diff.<driver>.command

カスタムdiffドライバーコマンド。詳細については gitattributes(5) を参照してください。

diff.<driver>.xfuncname

diffドライバーがハンクヘッダーを認識するために使用する必要がある正規表現。内蔵パターンを使用することもできます。詳細については gitattributes(5) を参照してください。

diff.<driver>.binary

このオプションをtrueに設定すると、diffドライバーがファイルをバイナリとして処理します。詳細については gitattributes(5) を参照してください。

diff.<driver>.textconv

ファイルのテキスト変換バージョンを生成するためにdiffドライバーが呼び出す必要のあるコマンド。変換の結果は、人間が読める形式のdiffを生成するために使用されます。詳細については gitattributes(5) を参照してください。

diff.<driver>.wordRegex

diffドライバーが単語(words)を1行に分割するために使用する必要がある正規表現。詳細については gitattributes(5) を参照してください。

diff.<driver>.cachetextconv

このオプションをtrueに設定すると、diffドライバーがテキスト変換出力をキャッシュするようになります。詳細については gitattributes(5) を参照してください。

diff.tool

git-difftool(1) によって使用されるdiffツールを制御します。この変数は、 merge.tool で構成された値をオーバーライドします。以下のリストは、有効な組み込み値を示しています。その他の値はカスタムdiffツールとして扱われ、対応する difftool.<tool>.cmd 変数が定義されている必要があります。

diff.guitool

-g/--gui フラグが指定されている場合に、 git-difftool(1) が使用するdiffツールを制御します。この変数は、 merge.guitool で構成された値をオーバーライドします。以下のリストは、有効な組み込み値を示しています。その他の値はカスタムdiffツールとして扱われ、対応する difftool.<guitool>.cmd 変数が定義されている必要があります。

  • araxis

  • bc

  • bc3

  • bc4

  • codecompare

  • deltawalker

  • diffmerge

  • diffuse

  • ecmerge

  • emerge

  • examdiff

  • guiffy

  • gvimdiff

  • gvimdiff1

  • gvimdiff2

  • gvimdiff3

  • kdiff3

  • kompare

  • meld

  • nvimdiff

  • nvimdiff1

  • nvimdiff2

  • nvimdiff3

  • opendiff

  • p4merge

  • smerge

  • tkdiff

  • vimdiff

  • vimdiff1

  • vimdiff2

  • vimdiff3

  • winmerge

  • xxdiff

diff.indentHeuristic

このオプションを false に設定すると、パッチを読みやすくするためにdiffハンク境界をシフトするデフォルトのヒューリスティックが無効になります。

diff.algorithm

diffアルゴリズムを選択します。 派生形は以下のとおりです:

default, myers

基本的な貪欲な差分アルゴリズム。現在、これがデフォルトです。

minimal

より多くの時間を費やして。可能な限り最小の差分が生成されるようにします。

patience

パッチを生成するときは、patience diff(忍耐差分)アルゴリズムを使用してください。

histogram

このアルゴリズムは、忍耐アルゴリズムを拡張して、「発生頻度の低い共通要素をサポート」(support low-occurrence common elements)します。

diff.wsErrorHighlight

差分の context または old または `new 行の空白エラー(whitespace errors)を強調表示します。複数の値はコンマで区切られ、 none は前の値をリセットし、 default はリストを new にリセットし、 allold,new,context の省略形です。空白のエラー(whitespace errors)は color.diff.whitespace で色分けされています。コマンドラインオプション --ws-error-highlight=<kind> はこの設定を上書きします。

diff.colorMoved

有効な <mode> またはtrueのいずれかに設定すると、diff内の移動された行が異なる色で表示されます。有効なモードの詳細については、 git-diff(1)--color-moved を参照してください。単にtrueに設定すると、デフォルトのカラーモードが使用されます。 falseに設定すると、移動した行は色付けされません。

diff.colorMovedWS

このオプションは、例えば diff.colorMoved 設定を使用して移動した行に色を付ける場合、スペース(spaces)をどのように扱うかを <mode> で制御します。有効なモードの詳細については git-diff(1)--color-moved-ws を参照してください。

difftool.<tool>.path

指定のツール(<tool>)のパスを上書きします。これは、あなたのツールがPATHにない場合に役立ちます。

difftool.<tool>.cmd

指定のdiffツール(<tool>)を呼び出すコマンドを指定します。指定されたコマンドは、次の変数を使用してシェルで評価されます: LOCAL は、diff pre-imageの内容を含む一時ファイルの名前に設定され、 REMOTE は、diff post-imageの内容を含む一時ファイルの名前に設定されます。

difftool.prompt

diffツールを呼び出す前にプロンプトを表示します。

extensions.objectFormat

使用するハッシュアルゴリズムを指定します。 許容値は sha1sha256 です。 指定しない場合、 sha1 が想定されます。 core.repositoryFormatVersion が1でない限り、このキーを指定するとエラーになります。

注意: この設定は、git-init(1) または git-clone(1) によってのみ設定する必要があることに注意してください。 初期化後に変更しようとすると機能せず、診断が難しい問題が発生します。

fastimport.unpackLimit

git-fast-import(1) によってインポートされたオブジェクトの数がこの制限を下回る場合、オブジェクトは緩いオブジェクト(loose object)ファイルに解凍されます。 ただし、インポートされたオブジェクトの数がこの制限以上の場合、パックはパックとして保存されます。 fast-import(高速インポート)からパックを保存すると、特に低速のファイルシステムで、インポート操作をより速く完了することができます。 設定されていない場合は、代わりに transfer.unpackLimit の値が使用されます。

feature.*

feature. で始まる構成設定は、他の構成設定のグループのデフォルトを変更します。 これらのグループは、Git開発者コミュニティによって推奨されるデフォルトとして作成されており、変更される可能性があります。 特に、新しい構成オプションが異なるデフォルトで追加される場合があります。

feature.experimental

Gitの新機能であり、将来のデフォルトで検討されている構成オプションを有効にします。 ここに含まれる構成設定は、マイナーバージョンの更新を含め、リリースごとに追加または削除される場合があります。 これらの設定は非常に新しいため、意図しない相互作用が発生する可能性があります。 実験的な機能に関するフィードバックを提供したい場合は、この設定を有効にしてください。 新しいデフォルト値は以下のとおりです:

  • fetch.negotiationAlgorithm=skipping は、一度により多くのコミットをスキップし、ラウンドトリップの数を減らすことで、フェッチネゴシエーション時間を改善できます。

feature.manyFiles

作業ディレクトリに多数のファイルがあるリポジトリを最適化する構成オプションを有効にします。 多くのファイルがあると、 git statusgit checkout などのコマンドが遅くなる可能性があり、これらの新しいデフォルトによりパフォーマンスが向上します:

  • index.version=4 インデックスのpath-prefix圧縮を有効にします。

  • core.untrackedCache=true 追跡されていないキャッシュを有効にします。この設定は、mtimeがマシンで機能していることを前提としています。

fetch.recurseSubmodules

このオプションは、 git fetch(および git pull の基になるフェッチ)が入力されたサブモジュールに再帰的にフェッチするかどうかを制御します。 このオプションは、ブール値または on-demand のいずれかに設定できます。 ブール値に設定すると、フェッチとプルの動作が変更され、trueに設定されている場合は無条件にサブモジュールに再帰し、falseに設定されている場合はまったく再帰しません。 on-demand に設定すると、フェッチとプルは、スーパープロジェクトがサブモジュールの参照を更新するコミットを取得したときにのみ、入力されたサブモジュールに再帰します。 デフォルトは 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ネイティブ転送を介してフェッチされるオブジェクトの数がこの制限を下回る場合、オブジェクトは緩いオブジェクト(loose object)ファイルに解凍されます。 ただし、受信したオブジェクトの数がこの制限以上の場合、受信したパックは、欠落しているデルタベースを追加した後、パックとして保存されます。 プッシュからパックを保存すると、特に低速のファイルシステムで、プッシュ操作をより速く完了することができます。 これが設定されていない場合は、代わりに transfer.unpackLimit の値が使用されます。

fetch.prune

trueの場合、fetchはコマンドラインで --prune オプションが指定されたかのように自動的に動作します。 remote.<name>.prune および git-fetch(1) の「PRUNING」セクションも参照してください。

fetch.pruneTags

trueの場合、フェッチは、まだ設定されていない場合、刈り込み(pruning)時に refs/tags/*:refs/tags/* refspecが提供されたかのように自動的に振る舞います。 これにより、このオプションと fetch.prune の両方を設定して、アップストリーム参照への 1=1 マッピングを維持できます。 remote.<name>.pruneTags および git-fetch(1) の「PRUNING」セクションも参照してください。

fetch.output

ref updateステータスの出力方法を制御します。 有効な値は fullcompact です。 デフォルト値は full です。 詳細については、 git-fetch(1) の「OUTPUT」セクションを参照してください。

fetch.negotiationAlgorithm

サーバーによって送信されるパックファイルの内容をネゴシエートするときに、ローカルリポジトリ内のコミットに関する情報がどのように送信されるかを制御します。 skipping に設定すると、より速く収束するためにコミットをスキップするアルゴリズムを使用しますが、必要以上にパックファイルが大きくなる可能性があります。 または、 noop に設定して情報をまったく送信しないようにします。これにより、ほぼ確実に必要以上のパックファイルが作成されますが、ネゴシエーション手順はスキップされます。 デフォルトは default で、コミットをスキップしないデフォルトのアルゴリズムを使用するようにGitに指示します(サーバーがコミットまたはその子孫の1つを確認した場合を除く)。 feature.experimental が有効になっている場合、この設定はデフォルトで skipping になります。 値が不明な場合、 git fetch でエラーが発生します。

git-fetch(1)--negotiate-only および --negotiation-tip オプションも参照してください。

fetch.showForcedUpdates

falseに設定すると、 git-fetch(1) および git-pull(1) コマンドで --no-show-forced-updates が有効になります。 デフォルトはtrueです。

fetch.parallel

一度に並行して実行されるフェッチ操作の最大数を指定します(サブモジュール、または、git-fetch(1)--multiple オプションが有効な場合はリモート)。

値0は、適切なデフォルトを提供します。 設定されていない場合、デフォルトで1になります。

サブモジュールの場合、この設定は、 submodule.fetchJobs 構成設定を使用してオーバーライドできます。

fetch.writeCommitGraph

リモートからパックファイルをダウンロードするすべての git fetch コマンドの後でcommit-graphを書き込むには、trueに設定します。 --split オプションを使用すると、ほとんどの実行で、既存のcommit-graphファイルの上に非常に小さなcommit-graphファイルが作成されます。 場合によっては、これらのファイルがマージされ、書き込みに時間がかかることがあります。 更新されたcommit-graphファイルがあると、 git merge-basegit push -fgit log --graph などの多くのGitコマンドのパフォーマンス改善に役立ちます。 デフォルトはfalseです。

format.attach

format-patch のデフォルトとして マルチパート/混合の添付(multipart/mixed attachments)を有効にします。値は二重引用符("...")で囲まれた文字列にすることもできます。これにより、添付ファイルがデフォルトとして有効になり、文字列が境界として設定されます。 git-format-patch(1)--attach オプションを参照してください。

format.from

--from オプションのデフォルト値をformat-patchに提供します。ブール値、または名前と電子メールアドレスを受け入れます。 falseの場合、format-patchはデフォルトで --no-from になり、パッチメールの From: フィールドに直接コミット作成者を使用します。 trueの場合、format-patchはデフォルトで --from になり、パッチメールの From: フィールドにあなたのコミッターIDを使い、異なる場合にはパッチメールの本文に From: フィールドを含めます。 ブール値でない値を設定した場合、format-patch はあなたのコミッターIDの代わりにその値を使用します。 デフォルトは false です。

format.numbered

パッチ件名のシーケンス番号を有効または無効にできるブール値。 デフォルトは「auto」で、複数のパッチがある場合にのみ有効になります。 「true」または「false」に設定することで、すべてのメッセージに対して有効または無効にできます。 git-format-patch(1)--numbered オプションを参照してください。

format.headers

メールで送信するパッチに含める追加の電子メールヘッダー。 git-format-patch(1) を参照してください。

format.to
format.cc

メールで送信するパッチに含める追加の受信者。 git-format-patch(1)--to および` --cc` オプションを参照してください。

format.subjectPrefix

format-patchのデフォルトは、 [PATCH] 件名接頭辞 を持つファイルを出力することです。 この変数を使用して、その接頭辞を変更します。

format.coverFromDescription

ブランチの説明を使用してカバーレターのどの部分にデータを入力するかを決定するためのformat-patchのデフォルトモード。 git-format-patch(1)--cover-from-description オプションを参照してください。

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 コマンドのpretty形式のデフォルト。 git-log(1)git-show(1)git-whatchanged(1) を参照してください。

format.thread

git format-patch のデフォルトのスレッドスタイル。 ブール値 または shallow または deep にすることができます。 shallow スレッドは、すべてのメールをシリーズの先頭にに対して返信します。先頭は、カバーレター、 --in-reply-to 、最初のパッチメールの順に選択されます。 deep スレッドは、すべてのメールを前のメールに返信します。 true のブール値は shallow と同じであり、 false値はスレッド化を無効にします。

format.signOff

デフォルトでformat-patchの -s/--signoff オプションを有効にできるブール値。 注意 パッチに「Signed-off-by」トレーラーを追加することは意識的な行為である必要があり、同じオープンソースライセンスの下でこの作品を提出する権利があることを証明することを意味します。 詳細については、「SubmittingPatches」ドキュメントを参照してください。

format.coverLetter

format-patchが呼び出されたときにカバーレターを生成するかどうかを制御するブール値ですが、さらに「auto」に設定して、複数のパッチがある場合にのみカバーレターを生成することができます。 デフォルトはfalseです。

format.outputDirectory

現在の作業ディレクトリの代わりに、結果のファイルを保存するカスタムディレクトリを設定します。 すべてのディレクトリコンポーネントが作成されます。

format.filenameMaxLength

format-patch コマンドによって生成される出力ファイル名の最大長。 デフォルトは64です。--filename-max-length=<n> コマンドラインオプションで上書きできます。

format.useAutoBase

format-patch のオプションである --base=auto をデフォルトで有効にするためのブール値です。 whenAble に設定すると、適切なベースがある場合に --base=auto を有効にし、それ以外の場合はフォーマット終了せずにベース情報の追加をスキップすることもできます。

format.notes

format-patchの --notes オプションのデフォルト値を提供します。 ブール値、またはnotesを取得する場所を指定するrefを受け入れます。 falseの場合、format-patchのデフォルトは --no-notes です。 trueの場合、format-patchのデフォルトは --notes です。 非ブール値に設定されている場合、format-patchのデフォルトは --notes=<ref> です。ここで、 ref は指定した非ブール値です。 デフォルトはfalseです。

ref ref/notes/true を使用したい場合は、代わりにそのリテラルを使用してください。

この構成は、複数のnotes refを含めるために複数回指定できます。その場合、渡された複数の --[no-]notes[=] オプションと同様に動作します。つまり、値 true はデフォルトのnotesを表示し、値 <ref> はそのnotes ref からのnotesも表示し、値 false はそれ以前の設定を無効にし、notesを表示しません。

例えば以下の場合、

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

refs/notes/bar からのnotesのみが表示されます。

filter.<driver>.clean

チェックイン時にワークツリーファイルのコンテンツをブロブに変換するために使用されるコマンド。 詳細については、 gitattributes(5) を参照してください。

filter.<driver>.smudge

チェックアウト時にブロブオブジェクトのコンテンツをワークツリーファイルに変換するために使用されるコマンド。 詳細については、 gitattributes(5) を参照してください。

fsck.<msg-id>

fsck中に、gitは、現在のバージョンのgitでは生成されず、 transfer.fsckObjects が設定されている場合はネットワーク経由で送信されない、レガシーデータの問題を検出する場合があります。この機能は、そのようなデータを含むレガシーリポジトリの操作をサポートすることを目的としています。

fsck.<msg-id> 設定は、 git-fsck(1) によって取得されますが、代わりに、そのようなデータセット receive.fsck.<msg-id> のプッシュを受け入れるか、または、クローンまたはフェッチのセットである fetch.fsck.<msg-id> を使用します。

この文書の残りの部分では、簡潔にするために fsck.* 変数について説明していますが、対応する receive.fsck.* 変数と fetch.<msg-id>.* 変数にも同じことが当てはまります。

color.uicore.editor のような変数とは異なり、 receive.fsck.<msg-id>fetch.fsck.<msg-id> 変数は、設定されていない場合、 fsck.<msg-id> 構成にフォールバックしません。さまざまな状況で同じfsck設定を均一に構成するには、3つすべてを同じ値に設定する必要があります。

fsck.<msg-id> が設定されている場合、 fsck.<msg-id> の値を errorwarnignore のいずれか一つとすることにより、エラーを警告に切り替える事もでき、その逆も可能です。そして <msg-id> の部分はメッセージIDです。便利なように、fsckはエラー/警告メッセージの前にメッセージIDを付けます。たとえば「missingEmail: invalid author/committer line - missing email」は、 fsck.missingEmail = ignore を設定するとその問題が非表示になることを意味します。

一般に、これらの問題のあるオブジェクトが共有する破損の種類をリストして無視するのではなく、 fsck.skipList に問題のある既存のオブジェクトを列挙することをお勧めします。前者を実行すると、同じ破損の新しいインスタンスが見過ごされる可能性があります。

不明な fsck.<msg-id> 値を設定すると、fsckが停止(die)しますが、 receive.fsck.<msg-id>fetch.fsck.<msg-id> に対して同じことを行うと、gitは単に警告するだけです。

fsck.skipList

非致命的な理由により既に壊れている(broken)ことが分かっているため無視する必要があるオブジェクト名(1行につき1つの省略されてないSHA-1)のリストへのパス。Git 2.20 以降では、コメント(#)文字から行末までと、空行と、先頭と末尾の空白(whitespace)は無視されます。それより古いバージョンでは1行につき1つのSHA-1以外は全てエラーになります。

この機能は、無効なコミッターの電子メールアドレスなど、初期のコミットにもかかわらず、安全に無視できるエラーを含む、確立されたプロジェクトを受け入れる必要がある場合に役立ちます。 注意: この設定では、corruptオブジェクトをスキップすることはできません。

fsck.<msg-id> と同様に、この変数に対応する receive.fsck.skipList 派生と fetch.fsck.skipList 派生があります。

color.uicore.editor のような変数とは異なり、 receive.fsck.skipList 変数と fetch.fsck.skipList 変数は、設定されていない場合、 fsck.skipList 構成にフォールバックしません。さまざまな状況で同じfsck設定を均一に構成するには、3つすべてを同じ値に設定する必要があります。

古いバージョンのGit(2.20より前)では、オブジェクト名リストを並べ替える必要があることが文書化されています。これは必須ではなく、オブジェクト名は任意の順序で表示できますが、リストを読み取るときに、内部バイナリ検索実装の目的でリストが並べ替えられているかどうかを追跡しました。これにより、既に並べ替えられたリストでは作業を節約できます。膨大なリストがない限り、リストを事前に並べ替える必要はありませんでした。 Gitバージョン2.20以降では、代わりにハッシュ実装が使用されるため、リストを事前に並べ替える必要はありません。

gc.aggressiveDepth

git gc --aggressive で使用されるデルタ圧縮アルゴリズムで使用される深さパラメーター。これはデフォルトで50に設定されています。これは --aggressive が使用されていない場合の --depth オプションのデフォルトです。

詳細については git-repack(1)--depth オプションの文書を参照してください。

gc.aggressiveWindow

git gc --aggressive で使用されるデルタ圧縮アルゴリズムで使用されるウィンドウサイズパラメータ。これはデフォルトで250に設定されています。これは、 --window のデフォルト値の10よりもはるかに積極的なウィンドウサイズです。

詳細については、 git-repack(1)--window オプションの文書を参照してください。

gc.auto

リポジトリにおおよそ指定の値より多くのルーズオブジェクトがある場合、 git gc --auto はそれらをパックします。一部の磁器コマンドは、このコマンドを使用して、軽量のガベージコレクションを時々実行します。デフォルト値は6700です。

これを0に設定すると、ルーズオブジェクトの数に基づく自動パッキングが無効にななります。また、他のヒューリスティックな git gc --auto が、 gc.autoPackLimit などの作業があるかどうかを判断するためにこの値を使用します。

gc.autoPackLimit

リポジトリに * .keep ファイルでマークされていないパックがこの設定値より多くある場合、 git gc --auto はそれらを1つの大きなパックに統合します。デフォルト値は50です。これを0に設定すると、無効になります。 gc.auto を0に設定すると、この設定も無効になります。

以下の gc.bigPackThreshold 構成変数を参照してください。この設定を使用中は、自動パックの制限がどのように機能するかに影響します。

gc.autoDetach

システムがサポートしている場合は git gc --auto は即座戻り、実行はバックグラウンドで行われます。デフォルトはtrueです。

gc.bigPackThreshold

ゼロ以外の場合、 git gc の実行時に、この設定値より大きいすべてのパックが保持されます。これは --keep-largest-pack と非常に似ていますが、最大のパックだけでなく、しきい値を満たす全てのパックが保持される点が異なります。デフォルトはゼロです。 kmg の一般的な単位接尾辞がサポートされています。

注意: 保持されるパックの数が gc.autoPackLimit を超える場合、この構成変数は無視され、基本パックを除くすべてのパックが再パックされることに注意してください。再パック後、パックの数は gc.autoPackLimit を下回り、再び gc.bigPackThreshold が尊重されるでしょう。

git repack がスムーズに実行されると推定されるメモリ量が利用できず、かつ、 gc.bigPackThreshold が設定されていない場合、最大のパックも除外されます(これは、 --keep-largest-pack を指定して git gc を実行するのと同じです)。

gc.writeCommitGraph

trueの場合、 git-gc(1) が実行されると、 gcはcommit-graphファイルを書き換えます。 git gc --auto を使用する場合、ハウスキーピングが必要な場合はコミットグラフが更新されます。デフォルトはtrueです。詳細については git-commit-graph(1) を参照してください。

gc.logExpiry

ファイルgc.logが存在する場合、 git gc --auto はそのコンテンツを出力し、そのファイルが「gc.logExpiry」より古い場合を除いて、実行する代わりにステータス0で終了します。デフォルトは「1.day」です。その他の値の指定方法については gc.pruneExpire を参照してください。

gc.packRefs

リポジトリで git pack-refs を実行すると、HTTPなどの馬鹿プロトコル(dumb transport) を介して 1.5.1.2 より前のGitバージョンではクローンが作成できなくなります。この変数は、「git gc」が「git pack-refs」を実行するかどうかを決定します。これを notbare に設定して、すべての非ベアリポジトリ内で有効にするか、ブール値に設定することができます。 デフォルトは true です。

gc.pruneExpire

「git gc」を実行すると、prune --expire 2.weeks.ago が呼び出されます。この構成変数で猶予期間をオーバーライドします。 値「now」を使用してこの猶予期間を無効にし、到達不能なオブジェクトを常にすぐに剪定(prune)するか、「never」を使用して剪定を抑制することができます。この機能は「git gc」がリポジトリに書き込む別のプロセスと同時に実行される場合の破損を防ぐのに役立ちます。 git-gc(1) の「NOTES」セクションを参照してください。

gc.worktreePruneExpire

git gc が実行されると、 git worktree prune --expire3.months.ago が呼び出されます。この構成変数を使用して、別の猶予期間を設定できます。値「now」を使用して猶予期間を無効にし、 $GIT_DIR/worktrees をすぐに剪定(prune)するか、「never」を使用して剪定を抑制することができます。

gc.reflogExpire
gc.<pattern>.reflogExpire

「git reflog expire」は、この時間より古いreflogエントリを削除します。デフォルトは90日です。値「now」はすべてのエントリをすぐに期限切れにし、「never」は期限切れを完全に抑制します。中央に「<pattern>」(例:「refs/stash」)がある場合、設定は <pattern> に一致するrefにのみ適用されます。

gc.reflogExpireUnreachable
gc.<pattern>.reflogExpireUnreachable

git reflog expire は、この時間より古いreflogエントリを削除し、現在の先端(the current tip)から到達不能にします。デフォルトは30日です。値「now」はすべてのエントリをすぐに期限切れにし、「never」は期限切れを完全に抑制します。中央に「<pattern>」(例:「refs/stash」)がある場合、設定は <pattern> に一致するrefにのみ適用されます。

これらのタイプのエントリは通常、 git commit--amend または git rebase を使用した結果として作成され、修正またはリベースが発生する前のコミットです。これらの変更は現在のプロジェクトの一部ではないため、ほとんどのユーザーはそれらをより早く期限切れにしたいと思うでしょう。そのため、デフォルトは gc.reflogExpire よりも積極的です。

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" (git-CVSエミュレーター経由)です。

gitcvs.enabled

このリポジトリに対してCVSサーバー・インターフェースが有効になっているかどうか。 git-cvsserver(1) を参照してください。

gitcvs.logFile

CVS サーバインターフェイスが様々なことを記録するログファイルへのパスです。 git-cvsserver(1) を参照してください。

gitcvs.usecrlfattr

trueの場合、サーバーはファイルの行末変換属性を検索して、使用する -k モードを決定します。 属性がGitにファイルをテキストとして処理させる場合、 -k モードは空白(blank)のままになるため、CVSクライアントはファイルをテキストとして処理します。 それらがテキスト変換を抑制する場合、ファイルは -kb モードで設定されます。これにより、クライアントが他の方法で行う可能性のある改行の変更が抑制されます。 属性でファイルタイプを決定できない場合は、gitcvs.allBinary が使用されます。 gitattributes(5) を参照してください。

gitcvs.allBinary

これは、 gitcvs.usecrlfattr が使用する「正しい -kb モード」(correct -kb mode)で解決しない場合に使用されます。 trueの場合、未解決のファイルはすべてモード -kb でクライアントに送信されます。 これにより、クライアントはそれらをバイナリファイルとして扱い、改行が変更されないようにします。 または、 guess に設定されている場合は、ファイルの内容が調べられ、 core.autocrlf と同様に、バイナリであるかどうかが判断されます。

gitcvs.dbName

Gitリポジトリから派生したリビジョン情報をキャッシュするためにgit-cvsserverによって使用されるデータベース。 正確な意味は、使用するデータベースドライバーによって異なります。 SQLite(デフォルトのドライバー)の場合、これはファイル名です。 変数の置換をサポートします(詳細については、 git-cvsserver(1) を参照してください)。 セミコロン(;)を含めることはできません。 デフォルトは %Ggitcvs.%m.sqlite です。

gitcvs.dbDriver

使用するPerlDBIドライバー。 ここで使用可能なドライバーを指定できますが、機能しない場合があります。 git-cvsserverは DBD::SQLite でテストされています。 DBD::Pg で動作するという報告がありますが、 `DBD::mysql で動作しないことが報告されています。 実験的機能です。 二重コロン(::)を含めることはできません。 デフォルトは SQLite です。 git-cvsserver(1) を参照してください。

gitcvs.dbUser, gitcvs.dbPass

データベースのユーザーとパスワード。 SQLiteにはデータベースユーザーやパスワードの概念がないため、 gitcvs.dbDriver を設定する場合にのみ役立ちます。 gitcvs.dbUser は変数の置換をサポートしています(詳細については git-cvsserver(1) を参照してください)。

gitcvs.dbTableNamePrefix

データベーステーブル名のプレフィックス。 使用されるデータベーステーブルの名前の前に付けられ、単一のデータベースを複数のリポジトリに使用できるようにします。 変数の置換をサポートします(詳細については、 git-cvsserver(1) を参照してください)。 アルファベット以外の文字はすべてアンダースコアに置き換えられます。

gitcvs.usecrlfattrgitcvs.allBinary を除くすべてのgitcvs変数は、 gitcvs.<access_method>.<varname> (access_method は "ext" と "pserver" のいずれか)として指定することもできます。それらは、指定のアクセス方法(<access_method>)にのみ適用されます。

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) を参照してください。

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

trueに設定されている場合、デフォルトで --extended-regexp オプションを有効にします。 grep.patternType オプションが default 以外の値に設定されている場合、このオプションは無視されます。

grep.threads

使用するgrepワーカースレッドの数。 詳細については、 git-grep(1)grep.threads を参照してください。

grep.fallbackToNoIndex

trueに設定すると、 git grep がgitリポジトリの外部で実行される場合は、 git grep --no-index にフォールバックします。 デフォルトはfalseです。

gpg.program

PGP署名を作成または検証するときは、$PATH にある gpg の代わりにこのカスタムプログラムを使用します。 プログラムはGPGと同じコマンドラインインターフェイスをサポートする必要があります。つまり、切り離された署名(detached signature)を検証するには、 gpg --verify $signature - <$file が実行され、 プログラムは、コード0で終了することにより、適切な署名を通知することが期待されます。PGP ASCII-armor の分離署名(ASCII-armored detached signature)を生成するために、 gpg -bsau $key の標準入力には、署名する内容が入力され、プログラムはその結果を標準出力に送信することが期待されています。

gpg.format

--gpg-sign で署名するときに使用するキー形式を指定します。 デフォルトは openpgp で、別の可能な値は x509 です。

gpg.<format>.program

これを使用して、選択した署名形式に使用されるプログラムをカスタマイズします。 ( gpg.programgpg.format 参照) gpg.program は、 gpg.openpgp.program の歴史的同義語として引き続き使用できます。 gpg.x509.program のデフォルト値は gpgsm です。

gpg.minTrustLevel

署名検証(signature verification)の最小信頼(trust)レベルを指定します。 このオプションが設定されていない場合、マージ操作の署名検証には、少なくとも marginal 信頼(trust)のあるキーが必要です。 署名の検証を実行する他の操作には、少なくとも undefined の信頼を持つキーが必要です。 このオプションを設定すると、すべての操作に必要な信頼レベルが上書きされます。 サポートされている値は以下のとおりです(重要度の昇順):

  • undefined

  • never

  • marginal

  • fully

  • ultimate

gui.commitMsgWidth

git-gui(1) のコミットメッセージウィンドウの幅を定義します。 「75」がデフォルトです。

gui.diffContext

git-gui(1) によるdiffの呼び出しで使用するコンテキスト行の数を指定します。 デフォルトは「5」です。

gui.displayUntracked

git-gui(1) がファイルリストに追跡されていないファイルを表示するかどうかを決定します。 デフォルトは「true」です。

gui.encoding

git-gui(1) および gitk(1) でファイルの内容を表示するために使用するデフォルトの文字エンコードを指定します。 関連するファイルの「encoding」属性を設定することでオーバーライドできます(gitattributes(5) 参照)。 このオプションが設定されていない場合、ツールはデフォルトでロケールエンコーディングになります。

gui.matchTrackingBranch

git-gui(1) で作成された新しいブランチが、デフォルトで名前が一致するリモートブランチを追跡するかどうかを決定します。 デフォルトは「false」です。

gui.newBranchTemplate

git-gui(1) を使用して新しいブランチを作成するときに、推奨される名前として使用されます。

gui.pruneDuringFetch

git-gui(1) がフェッチの実行時にリモート追跡ブランチを刈り込み(prune)する必要がある場合は「true」。 デフォルト値は「false」です。

gui.trustmtime

git-gui(1) がファイル変更のタイムスタンプを信頼するかどうかを決定します。 デフォルトでは、タイムスタンプは信頼されていません。

gui.spellingDictionary

git-gui(1) でコミットメッセージのスペルチェックに使用される辞書を指定します。「none」に設定すると、スペルチェックがオフになります。

gui.fastCopyBlame

trueの場合、 git gui blame は、元の場所(original location)の検出に -C -C ではなく -C を使用します。 コピーの検出が完全ではなくなる代わりに、巨大なリポジトリでのblameが大幅に速くなります。

gui.copyBlameThreshold

英数字(alphanumeric)文字で測定された、 git gui blame の元の位置(original location)検出で使用するしきい値を指定します。 コピー検出の詳細については、 git-blame(1) のマニュアルを参照してください。

gui.blamehistoryctx

「Show History Context」(履歴コンテキストの表示)メニュー項目が git gui blame から呼び出されたときに、選択したコミットの gitk(1) に表示する履歴コンテキストの範囲を日数で指定します。 この変数がゼロに設定されている場合、履歴全体が表示されます。

guitool.<name>.cmd

git-gui(1) Toolsメニューの対応する項目が呼び出されたときに実行するシェルコマンドラインを指定します。 このオプションは、すべてのツールに必須です。 コマンドは作業ディレクトリのルートから実行され、環境ではツールの名前を GIT_GUITOOL 、現在選択されているファイルの名前を FILENAME 、現在のブランチの名前を CUR_BRANCH として受け取ります(切り離されたヘッド(detached head)の場合、 CUR_BRANCH は空です)。

guitool.<name>.needsFile

GUIでdiffが選択されている場合にのみ、ツールを実行します。 FILENAME が空でないことを保証します。

guitool.<name>.noConsole

出力を表示するウィンドウを作成せずに、コマンドを黙って実行します。

guitool.<name>.noRescan

ツールの実行が終了した後、変更がないか作業ディレクトリを再スキャンしないでください。

guitool.<name>.confirm

ツールを実際に実行する前に、確認ダイアログを表示します。

guitool.<name>.argPrompt

ユーザーに文字列引数を要求し、それを ARGS 環境変数を介してツールに渡します。 引数の要求は確認を意味するため、これが有効になっている場合、「confirm」オプションは効果がありません。 オプションが true または yes または 1 に設定されている場合、ダイアログは組み込みの汎用プロンプトを使用します。 それ以外の場合は、変数の正確な値が使用されます。

guitool.<name>.revPrompt

ユーザーに有効なリビジョンを1つ要求し、 REVISION 環境変数を設定します。 それ以外は argPrompt と同様です。 argPrompt と一緒に使用できます。

guitool.<name>.revUnmerged

revPrompt サブダイアログにマージされていないブランチのみを表示します。 これは、マージやリベースに似たツールには役立ちますが、チェックアウトやリセットなどには役立ちません。

guitool.<name>.title

プロンプトダイアログに使用するタイトルを指定します。 デフォルトはツール名です。

guitool.<name>.prompt

ダイアログの上部、 argPrompt および revPrompt のサブセクションの前に表示する一般的なプロンプト文字列を指定します。 デフォルト値には実際のコマンドが含まれます。

help.browser

ヘルプをweb形式で表示するために使用されるブラウザーを指定します。 git-help(1) を参照してください。

help.format

git-help(1) で使用されるデフォルトのヘルプ形式を上書きします。 値として maninfowebhtml がサポートされています。 man がデフォルトです。 webhtml は同じ(same)です。

help.autoCorrect

gitがタイプミスを検出し、間違いにに類似した有効なコマンドを1つだけ識別できる場合、gitは正しいコマンドを提案しようとするか、提案を自動的に実行します。 可能な構成値は以下のとおりです:

  • 0 (デフォルト): 提案されたコマンドを表示します。

  • 正の数: 指定されたデシ秒単位(0.1秒単位)の秒数後に提案されたコマンドを実行します。

  • "immediate": 提案されたコマンドを即座に実行します。

  • "prompt": コマンドを実行するための提案と確認のプロンプトを表示します。

  • "never": 提案されたコマンドを実行も表示もしないでください。

help.htmlPath

HTMLドキュメントが存在するパスを指定します。 ファイルシステムのパスとURLがサポートされています。 ヘルプが「web」形式で表示される場合、HTMLページの前にこのパスが付けられます。 これはデフォルトでGitインストールのドキュメントパスになります。

http.proxy

通常は http_proxyhttps_proxyall_proxy 環境変数を使用して構成されたHTTPプロキシをオーバーライドします(curl(1) 参照)。 curlが理解できる構文に加えて、ユーザー名はパスワードなしでプロキシ文字列を指定でき、その場合、gitは他の資格情報の場合と同じ方法でプロキシ文字列を取得しようとします。 詳細については、 gitcredentials(7) を参照してください。 構文は [protocol://][user[:password]@]proxyhost[:port] です。 これは、リモートごとにオーバーライドできます。 remote.<name>.proxy を参照してください

http.proxyAuthMethod

HTTPプロキシに対して認証する方法を設定します。 これは、構成されたプロキシ文字列にユーザー名の部分が含まれている場合にのみ有効になります(つまり、 user@host または user@host:port 形式)。 これは、リモートごとにオーバーライドできます。 remote.<name>.proxyAuthMethod を参照してください。 どちらも GIT_HTTP_PROXY_AUTHMETHOD 環境変数でオーバーライドできます。 可能な値は以下のとおりです:

  • anyauth - 適切な認証方法を自動的に選択します。 プロキシは、407ステータスコードとサポートされている認証方法を使用した1つ以上のProxy-authenticateヘッダーを使用して、認証されていない要求に応答すると想定されます。 これがデフォルトです。

  • basic - HTTPベーシック認証

  • digest - HTTPダイジェスト認証。これにより、パスワードがクリアテキストでプロキシに送信されるのを防ぎます

  • negotiate - GSSネゴシエーション認証(curl(1)--negotiate オプションと比較してください)

  • ntlm - NTLM認証(curl(1)--ntlm オプションと比較してください)

http.proxySSLCert

HTTPSプロキシでの認証に使用するクライアント証明書を格納するファイルのパス名。 GIT_PROXY_SSL_CERT 環境変数でオーバーライドできます。

http.proxySSLKey

HTTPSプロキシでの認証に使用する秘密鍵を格納するファイルのパス名。 GIT_PROXY_SSL_KEY 環境変数でオーバーライドできます。

http.proxySSLCertPasswordProtected

プロキシSSL証明書に対するGitのパスワードプロンプトを有効にします。 それ以外の場合、証明書または秘密鍵が暗号化されていると、OpenSSLはユーザーにプロンプトを表示します。 GIT_PROXY_SSL_CERT_PASSWORD_PROTECTED 環境変数で上書きできます。

http.proxySSLCAInfo

HTTPSプロキシを使用するときにプロキシを検証するために使用する必要がある証明書バンドルを含むファイルへのパス名。 GIT_PROXY_SSL_CAINFO 環境変数でオーバーライドできます。

http.emptyAuth

ユーザー名またはパスワードを求めずに認証を試みます。 libcurlは通常、認証にユーザー名を必要とするため、これを使用して、URLにユーザー名を指定せずにGSS-Negotiate認証を試みることができます。

http.delegation

GSSAPI資格情報の委任を制御します。 バージョン7.21.7以降、libcurlでは委任がデフォルトで無効になっています。 ユーザー資格情報に関して、何を委任できるかをサーバーに通知するパラメーターを設定します。 GSS/kerberosで使用されます。 可能な値は以下のとおりです:

  • none - 委任を許可しないでください。

  • policy - OK-AS-DELEGATE フラグが Kerberos サービスチケットに設定されている場合にのみ委任します。これはレルムポリシー(realm policy)の問題です。

  • always - サーバーが無条件に委任できるようにします。

http.extraHeader

サーバーと通信するときに追加のHTTPヘッダーを渡します。 そのようなエントリが複数存在する場合は、それらすべてが追加のヘッダーとして追加されます。 システム構成から継承された設定をオーバーライドできるようにするには、値を空にすると、余分なヘッダーが空のリストにリセットされます。

http.cookieFile

以前に保存されたクッキー行を含むファイルのパス名。サーバーと一致する場合はGit httpセッションで使用する必要があります。 クッキーを読み取るファイルのファイル形式は、プレーンHTTPヘッダーまたは、Netscape/Mozilla クッキーファイル形式である必要があります(curl(1) 参照)。 注意: http.saveCookies が設定されていない限り、 http.cookieFile で指定されたファイルは入力としてのみ使用されることに注意してください。

http.saveCookies

設定されている場合、リクエスト中に受信したクッキーを http.cookieFile で指定されたファイルに保存します。 http.cookieFile が設定されていない場合は効果がありません。

http.version

サーバーと通信するときは、指定されたHTTPプロトコルバージョンを使用してください。 デフォルトを強制する場合、使用可能なデフォルトバージョンはlibcurlによって異なります。 現在、このオプションの可能な値は以下のとおりです:

  • HTTP/2

  • HTTP/1.1

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にlibcurlのデフォルトのsslバージョンを使用させ、明示的なhttp.sslversionオプションを無視するには、 GIT_SSL_VERSION を空の文字列に設定します。

http.sslCipherList

SSL接続をネゴシエートするときに使用するSSL暗号のリスト。 使用可能な暗号は、libcurlがNSSまたはOpenSSLのどちらに対して構築されたか、および使用中の暗号ライブラリの特定の構成によって異なります。 内部的には、これにより CURLOPT_SSL_CIPHER_LIST オプションが設定されます。 このリストの形式の詳細については、libcurlのドキュメントを参照してください。

GIT_SSL_CIPHER_LIST 環境変数で上書きできます。 gitにlibcurlのデフォルトの暗号リストを使用させ、明示的なhttp.sslCipherListオプションを無視するには、 GIT_SSL_CIPHER_LIST を空の文字列に設定します。

http.sslVerify

HTTPSをフェッチまたはプッシュするときにSSL証明書を検証するかどうか。 デフォルトはtrueです。 GIT_SSL_NO_VERIFY 環境変数で上書きできます。

http.sslCert

HTTPSをフェッチまたはプッシュするときのSSL証明書を含むファイル。 GIT_SSL_CERT 環境変数で上書きできます。

http.sslKey

HTTPSをフェッチまたはプッシュするときのSSL秘密鍵を含むファイル。 GIT_SSL_KEY 環境変数で上書きできます。

http.sslCertPasswordProtected

SSL証明書に対するGitのパスワードプロンプトを有効にします。 それ以外の場合、証明書または秘密鍵が暗号化されていると、OpenSSLはユーザーにプロンプトを表示します。 GIT_SSL_CERT_PASSWORD_PROTECTED 環境変数で上書きできます。

http.sslCAInfo

HTTPSをフェッチまたはプッシュするときにピア(peer)を検証(verify)するための証明書を含むファイル。 GIT_SSL_CAINFO 環境変数でオーバーライドできます。

http.sslCAPath

HTTPSをフェッチまたはプッシュするときにピア(peer)を検証(verify)するためのCA証明書を含むファイルを含むパス。 GIT_SSL_CAPATH 環境変数で上書きできます。

http.sslBackend

使用するSSLバックエンドの名前(例: openssl または schannel)。 cURLが実行時にSSLバックエンドを選択するためのサポートを欠いている場合、このオプションは無視されます。

http.schannelCheckRevoke

http.sslBackendschannel に設定されている場合にcURLで証明書失効チェックを実施または無効にするために使用されます。 設定されていない場合、デフォルトは true です。 Gitが一貫してエラーを出し、メッセージが証明書の失効ステータスの確認に関するものである場合にのみ、これを無効にする必要があります。 cURLが実行時に関連するSSLオプションを設定するためのサポートを欠いている場合、このオプションは無視されます。

http.schannelUseSSLCAInfo

cURL v7.60.0以降、セキュリティで保護されたチャネルのバックエンドは http.sslCAInfo を介して提供される証明書バンドルを使用できますが、これによりWindows証明書ストアが上書きされます。 これはデフォルトでは望ましくないため、 http.schannelUseSSLCAInfo がこの動作をオーバーライドしない限り、 schannel バックエンドが http.sslBackend を介して構成されている場合、Gitはデフォルトでそのバンドルを使用しないようにcURLに指示します。

http.pinnedpubkey

httpsサービスの公開鍵。 これは、PEMまたはDERでエンコードされた公開鍵ファイルのファイル名か、 sha256// で始まり、その後にbase64でエンコードされた公開鍵のsha256ハッシュが続く文字列のいずれかです。 libcurlの CURLOPT_PINNEDPUBLICKEY も参照してください。 このオプションが設定されているがcURLでサポートされていない場合、gitはエラーで終了します。

http.sslTry

通常のFTPプロトコルを介して接続する場合は、AUTH SSL/TLS と暗号化されたデータ転送を使用してみてください。 これは、FTPサーバーがセキュリティ上の理由でそれを必要とする場合、またはリモートFTPサーバーがそれをサポートする場合はいつでも安全に接続したい場合に必要になることがあります。 誤って構成されたサーバーで証明書検証エラーが発生する可能性があるため、デフォルトはfalseです。

http.maxRequests

並行して起動するHTTPリクエストの数。 GIT_HTTP_MAX_REQUESTS 環境変数でオーバーライドできます。 デフォルトは 5 です。

http.minSessions

リクエスト間で保持されるcurlセッションの数(スロット全体でカウント)。 http_cleanup() が呼び出されるまで、curl_easy_cleanup()で終了することはありません。 USE_CURL_MULTIが定義されていない場合、この値の上限は1になります。 デフォルトは1です。

http.postBuffer

リモートシステムにデータをPOSTするときにスマートHTTPトランスポートによって使用されるバッファーの最大サイズ(バイト単位)。 このバッファサイズより大きいリクエストの場合、 HTTP/1.1 と Transfer-Encoding: チャンクが使用され、ローカルで大規模なパックファイルが作成されるのを防ぎます。 デフォルトは1MiBで、ほとんどのリクエストでは十分です。

この制限を引き上げることは、チャンク転送エンコーディングを無効にする場合にのみ有効であるため、リモートサーバーまたはプロキシが HTTP/1.0 のみをサポートするか、HTTP標準に準拠していない場合にのみ使用する必要があることに注意してください。 この制限を引き上げることは、一般に、ほとんどのプッシュの問題に対して効果的な解決策ではありませんが、小さなプッシュに対してもバッファー全体が割り当てられるため、メモリー消費を大幅に増やす可能性があります。

http.lowSpeedLimit, http.lowSpeedTime

http.lowSpeedTime 秒より長いために、HTTP転送速度が http.lowSpeedLimit 未満の場合、転送は中止されます。 GIT_HTTP_LOW_SPEED_LIMIT および GIT_HTTP_LOW_SPEED_TIME 環境変数でオーバーライドできます。

http.noEPSV

curlによるEPSV ftpコマンドの使用を無効にするブール値。 これは、EPSVモードをサポートしていない一部の「貧弱な」ftpサーバーで役立ちます。 GIT_CURL_FTP_NO_EPSV 環境変数でオーバーライドできます。 デフォルトはfalseです(curlはEPSVを使用します)。

http.userAgent

HTTPサーバーに提示されるHTTP USER_AGENT文字列。 デフォルト値は、git/1.7.1などのクライアントGitのバージョンを表します。 このオプションを使用すると、この値を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://example.com/https の部分)。 このフィールドは、構成キーとURLの間で正確に一致する必要があります。

  2. ホスト/ドメイン名(例: https://example.com/example.com の部分)。 このフィールドは、構成キーとURLの間で一致する必要があります。 このレベルのすべてのサブドメインに一致するように、ホスト名の一部として * を指定することができます。 たとえば、 https://*.example.com/https://foo.example.com/ と一致しますが、 https://foo.bar.example.com/ とは一致しません。

  3. ポート番号(例: http://example.com:8080/8080 の部分)。 このフィールドは、構成キーとURLの間で正確に一致する必要があります。 省略されたポート番号は、照合する前に、スキームの正しいデフォルトに自動的に変換されます。

  4. パス(例: https://example.com/repo.gitrepo.git の部分)。 構成キーのパスフィールドは、URLのパスフィールドと正確に一致するか、スラッシュ(/)で区切られたパス要素のプレフィックスとして一致する必要があります。 これは、パス foo/ の設定キーがURLパス foo/bar と一致することを意味します。 プレフィックスは、スラッシュ(/)境界でのみ一致できます。 長い一致が優先されます(したがって、パス foo/bar の構成キーは、パス foo/ の構成キーよりもURLパス foo/bar によく一致します)。

  5. ユーザー名(例: https://user@example.com/repo.gituser の部分)。 構成キーにユーザー名がある場合は、URLのユーザー名と正確に一致する必要があります。 構成キーにユーザー名がない場合、その構成キーは任意のユーザー名(ユーザー名無しを含む)のURLと一致しますが、ユーザー名の構成キーよりも優先順位は低くなります。

上記のリストは、優先順位の高い順に並べられています。 構成キーのパスに一致するURLは、そのユーザー名に一致するURLよりも優先されます。 例えば、URLが https://user@example.com/foo/bar の場合、 https://user@example.com の設定キーの一致よりも https://example.com/foo の設定キーの一致が優先されます。

すべてのURLは、照合を試みる前に正規化されます(パスワード部分がURLに埋め込まれている場合、照合目的では常に無視されます)。これにより、スペルが異なる同等のURLが正しく照合されます。 環境変数の設定は、常に一致を上書きします。 照合されるURLは、Gitコマンドに直接指定されたURLです。 これは、リダイレクトの結果としてアクセスされたURLがマッチングに参加しないことを意味します。

i18n.commitEncoding

コミットメッセージの文字エンコーディングは保存されます。 Gitそれ自体は気にしませんが、この情報は必要です。 例えば、電子メールまたはgitkグラフィカル履歴ブラウザーからコミットをインポートする場合(そしておそらく将来の他の場所や他の磁器コマンドでも)です。例として linkgit:git-mailinfo[1] を参照してください。 デフォルトは utf-8 です。

i18n.logOutputEncoding

コミットメッセージの文字エンコーディングは、 git log やその仲間を実行するときに変換されます。

imap.folder

メールをドロップするフォルダー。通常はドラフトフォルダーです。 例:「INBOX.Drafts」とか「INBOX/Drafts」とか「[Gmail]/Drafts」です。必須です。

imap.tunnel

サーバーへの直接ネットワーク接続を使用する代わりに、コマンドがパイプされるIMAPサーバーへのトンネルをセットアップするために使用されるコマンド。 imap.host が設定されていない場合に必須です。

imap.host

サーバーを識別するURL。 非セキュア接続には imap:// プレフィックスを使用し、セキュア接続には imaps:// プレフィックスを使用します。 imap.tunnel が設定されている場合は無視されますが、それ以外の場合は必須です。

imap.user

サーバーにログインするときに使用するユーザー名。

imap.pass

サーバーにログインするときに使用するパスワード。

imap.port

サーバー上で接続する整数のポート番号。 デフォルトは、 imap:// ホストの場合は143、 imaps:// ホストの場合は993です。 imap.tunnel が設定されている場合は無視されます。

imap.sslverify

SSL/TLS接続で使用されるサーバー証明書の検証を有効/無効にするブール値。デフォルトは true です。 imap.tunnel が設定されている場合は無視されます。

imap.preformattedHTML

パッチを送信するときにhtmlエンコーディングの使用を有効/無効にするブール値。 htmlでエンコードされたパッチは <pre> で囲まれ、コンテンツタイプは text/html になります。皮肉なことに、このオプションを有効にすると、Thunderbirdはパッチを plane/text の format=fixed メールとして送信します。デフォルトは false です。

imap.authMethod

IMAPサーバーでの認証の認証方法を指定します。GitがNO_CURLオプションを使用してビルドされた場合、curlバージョンが7.34.0より古い場合、またはgit-imap-sendを --no-curl オプションを指定して実行している場合、サポートされるメソッドは CRAM-MD5 のみです。これが設定されていない場合、「git imap-send」は基本的なIMAPプレーンテキストLOGINコマンドを使用します。

index.recordEndOfIndexEntries

インデックスファイルに「End Of Index Entry」セクションを含めるかどうかを指定します。 これにより、マルチプロセッサマシンでのインデックスの読み込み時間が短縮されますが、2.20より前のバージョンのGitを使用してインデックスを読み取ると、「ignoring EOIE extension」というメッセージが表示されます。 index.threads が明示的に有効になっている場合はデフォルトで true 、それ以外の場合は false になります。

index.recordOffsetTable

インデックスファイルに「Index Entry Offset Table」セクションを含めるかどうかを指定します。 これにより、マルチプロセッサマシンでのインデックスの読み込み時間が短縮されますが、2.20より前のバージョンのGitを使用してインデックスを読み取ると、「ignoring IEOT extension」というメッセージが表示されます。 index.threadsが明示的に有効になっている場合はデフォルトで true 、それ以外の場合は false になります。

index.sparse

有効にすると、sparse-directory エントリを使用してインデックスを書き込みます。 core.sparseCheckoutcore.sparseCheckoutCone の両方が有効になっていない限り、これは効果がありません。 デフォルトは false です。

index.threads

インデックスをロードするときに生成するスレッドの数を指定します。 これは、マルチプロセッサマシンでのインデックスのロード時間を短縮することを目的としています。 0または true を指定すると、GitはCPUの数を自動検出し、それに応じてスレッドの数を設定します。 1または false を指定すると、マルチスレッドが無効になります。 デフォルトは true です。

index.version

新しいインデックスファイルを初期化するバージョンを指定します。 これは既存のリポジトリには影響しません。 feature.manyFiles が有効になっている場合、デフォルトは4です。

init.templateDir

テンプレートのコピー元のディレクトリを指定します。 (git-init(1) の「TEMPLATE DIRECTORY」セクションを参照してください。)

init.defaultBranch

デフォルトのブランチ名を上書きできます。例えば、新しいリポジトリを初期化するとき。

instaweb.browser

gitwebであなたの作業リポジトリをブラウズするために使用されるプログラムを指定します。 git-instaweb(1) を参照してください。

instaweb.httpd

あなたの作業リポジトリでgitwebを起動するためのHTTPデーモンコマンドライン。 git-instaweb(1) を参照してください。

instaweb.local

trueの場合、 git-instaweb(1) によって起動されたWebサーバーはローカルIP(local IP)(127.0.0.1)にバインドされます。

instaweb.modulePath

/usr/lib/apache2/modules の代わりに使用する git-instaweb(1) のデフォルトのモジュールパス。httpdがApacheの場合にのみ使用されます。

instaweb.port

gitweb httpdをバインドするポート番号。 git-instaweb(1) を参照してください。

interactive.singleKey

対話コマンドでは、ユーザーが1つのキーで1文字の入力を提供できるようにします(つまり、Enterキーを押さずに)。 現在、これは git-add(1)git-checkout(1)git-restore(1)git-commit(1)git-reset(1)git-stash(1)--patch モードで使用されています。 ポータブルキーストローク入力(portable keystroke input)が利用できない場合、この設定は黙って無視されることに注意してください。 Perlモジュール Term::ReadKey が必要です。

interactive.diffFilter

対話コマンド(git add --patch など)が色付きのdiffを表示すると、gitはこの構成変数で定義されたシェルコマンドを介してdiffをパイプします。 コマンドは、元のdiffの行と1対1の対応を保持している場合、人間に読みやすいようにdiffをさらにマークアップできます。 デフォルトは無効(フィルタリングなし)です。

log.abbrevCommit

trueの場合、 linkgit:git-log [1] と git-show(1)git-whatchanged(1)--abbrev-commit を想定させます。 このオプションは --no-abbrev-commit で上書きできます。

log.date

log コマンドのデフォルトの日時モードを設定します。 log.dateの値の設定は、 git log--date オプションと同様です。 詳細については、 git-log(1) を参照してください。

log.decorate

logコマンドで表示されるコミットのref名を出力します。 short が指定されている場合、ref名の接頭辞 refs/heads/refs/tags/refs/remotes/ は出力されません。 full が指定されている場合、完全なref名(接頭辞を含む)が出力されます。 auto が指定されている場合、出力が端末に送られる場合、ref名は short が指定されているかのように表示されます。それ以外の場合、ref名は表示されません。 これは、 git log--decorate オプションと同じです。

log.excludeDecoration

ログ装飾(log decorations)から指定されたパターンを除外します。 これは --decorate-refs-exclude コマンドラインオプションに似ていますが、構成オプションは --decorate-refs オプションで上書きできます。

log.diffMerges

マージコミットに使用されるデフォルトのdiff形式を設定します。 詳細については、 git-log(1)--diff-merges を参照してください。 デフォルトは separate です。

log.follow

true の場合、 git log は、単一の<path>が指定されたときに --follow オプションが使用されたかのように機能します。 これには --follow と同じ制限があります。つまり、複数のファイルを追跡するために使用することはできず、非線形履歴ではうまく機能しません。

log.graphColors

git log --graph で履歴線(history lines)を描画するために使用できる、コンマで区切られた色のリスト。

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」(protocol-v2.txtに説明があります)を送信するクライアントに応答し、プロトコルv2機能の広告(advertise)中にこの機能のサポートを広告します。 「allow」は「advertise」と同じですが、サーバーがこの機能のサポートを広告しない点が異なります。 これは、管理者が「allow」を構成し、遅れて「advertise」を構成できるため、(たとえば、)アトミックに更新できない負荷分散サーバーに役立ちます。

mailinfo.scissors

trueの場合、 git-mailinfo(1) (それゆえ git-am(1) も)は、コマンドラインで --scissors オプションが指定されているかのようにデフォルトで動作します。この機能がアクティブな場合、メッセージ本文から切り取り線(つまり、主に ">8" や "8<" や "-" で構成される)行とそれより前のすべてを削除します。

mailmap.file

拡張メールマップファイルの場所。リポジトリのルートにあるデフォルトのメールマップが最初にロードされ、次にこの変数が指すメールマップファイルがロードされます。メールマップファイルの場所は、リポジトリサブディレクトリ内、またはリポジトリの外部のどこかにあります。 git-shortlog(1)git-blame(1) を参照してください。

mailmap.blob

mailmap.file と同様ですが、値をリポジトリ内のブロブへの参照と見なします。 mailmap.filemailmap.blob の両方が指定されている場合、両方が解析され、 mailmap.file からのエントリが優先されます。この変数は、ベアリポジトリではデフォルトで HEAD:.mailmap になります。非ベアリポジトリでは、デフォルトで空になります。

maintenance.auto

このブール構成オプションは、一部のコマンドが通常の作業を行った後に git maintenance run --auto を実行するかどうかを制御します。 デフォルトはtrueです。

maintenance.strategy

この文字列設定オプションは、バックグラウンドメンテナンスのいくつかの推奨スケジュールの1つを指定する方法を提供します。 これは、 --task=<task> 引数が指定されていない場合、 git maintenance run --schedule=X コマンド中に実行されるタスクにのみ影響します。 さらに、 maintenance.<task>.schedule 構成値が設定されている場合、 maintenance.strategy によって提供される値の代わりにその値が使用されます。 戦略として指定可能な文字列は以下のとおりです:

  • none: このデフォルト設定は、どのスケジュールでもタスクが実行されないことを意味します。

  • incremental: この設定は、データを削除しない小さなメンテナンスアクティビティの実行に最適化されています。 これは gc タスクをスケジュールしませんが、 prefetch および commit-graph タスクを1時間ごとに実行し、 loose-objects および incremental-repack タスクを毎日実行し、 pack-refs タスクを毎週実行します。

maintenance.<task>.enabled

このブール構成オプションは、 git maintenance run--task オプションが指定されていない場合に、 <task> という名前のメンテナンスタスクを実行するかどうかを制御します。 --task オプションが存在する場合、これらの構成値は無視されます。 デフォルトでは、 maintenance.gc.enabled のみがtrueです。

maintenance.<task>.schedule

この設定オプションは、指定された <task>git maintenance run --schedule=<frequency> コマンド中に実行されるかどうかを制御します。 値は、 "hourly", "daily", "weekly" のいずれかである必要があります。

maintenance.commit-graph.auto

この整数値構成オプションは、 git maintenance run --auto の一部として commit-graph タスクを実行する頻度を制御します。 ゼロの場合、 commit-graph タスクは`--auto` オプションで実行されません。負の値を指定すると、タスクは毎回実行されます。 それ以外の場合、正の値は、commit-graphファイルにない到達可能なコミットの数が maintenance.commit-graph.auto の値以上であるときにコマンドを実行する必要があることを意味します。デフォルト値は100です。

maintenance.loose-objects.auto

この整数値構成オプションは、 git maintenance run --auto の一部として loose-objects タスクを実行する頻度を制御します。 ゼロの場合、 loose-objects タスクは --auto オプションでは実行されません。 負の値を指定すると、タスクは毎回実行されます。 それ以外の場合、正の値は、緩いオブジェクト(loose objects)の数が maintenance.loose-objects.auto の値以上であるときにコマンドを実行する必要があることを意味します。 デフォルト値は100です。

maintenance.incremental-repack.auto

この整数値構成オプションは、 git maintenance run --auto の一部として incremental-repack タスクを実行する頻度を制御します。 ゼロの場合、 incremental-repack タスクは --auto オプションでは実行されません。 負の値を指定すると、タスクは毎回実行されます。 それ以外の場合、正の値は、multi-pack-indexにないpack-fileの数が maintenance.incremental-repack.auto の値以上であるときにコマンドを実行する必要があることを意味します。 デフォルト値は10です。

man.viewer

ヘルプを man 形式で表示するために使用できるプログラムを指定します。 git-help(1) を参照してください。

man.<tool>.cmd

指定されたmanビューア(<tool>)を呼び出すコマンドを指定します。指定されたコマンドは、引数として渡されたマニュアルページを使用してシェルで評価されます。(git-help(1) を参照してください。)

man.<tool>.path

man 形式でヘルプを表示するために使用される可能性のある特定のツール(<tool>)のパスをオーバーライドします。 git-help(1) を参照してください。

merge.conflictStyle

マージ時に競合するハンクが作業ツリーファイルに書き出されるスタイルを指定します。 デフォルトは「merge」です。これは、 <<<<<<< 競合マーカー、一方の側で行われた変更、 ======= マーカー、もう一方の側で行われた変更、そして >>>>>>> マーカーというスタイルです。 別のスタイル「diff3」は、 ||||||| マーカーと元のテキストを ======= マーカーの前に追加します。

merge.defaultToUpstream

コミット引数なしでmergeが呼び出された場合は、リモート追跡ブランチに格納されている最後に観測された値を使用して、現在のブランチ用に構成されたアップストリームブランチをマージします。 branch.<currentbranch>.remote によって指定されたリモートのブランチに名前を付ける branch.<currentbranch>.merge の値が参照され、次に、それらは remote.<remote>.fetch を介して対応するリモート追跡ブランチにマッピングされ、そして、これらの追跡ブランチの先端がマージされます。 デフォルトは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

ブランチ名に加えて、マージされる実際のコミットからの最大「指定の数」の親コミットの1行説明をログメッセージに入力します。デフォルトはfalseで、trueは20の同義語です。

merge.suppressDest

統合ブランチの名前に一致するグロブをこの複数値の構成変数(multi-valued configuration variable)に追加することにより、これらの統合ブランチへのマージに対して計算されるデフォルトのマージメッセージは、タイトルから「into <branch name>」を省略します。

空の値を持つ要素を使用して、以前の構成エントリから蓄積されたグロブのリストをクリアできます。 merge.suppressDest 変数が定義されていない場合、下位互換性のためにデフォルト値の master が使用されます。

merge.renameLimit

マージ処理中に名前変更検出の網羅的な部分で考慮するファイルの数。 指定されない場合、デフォルトは diff.renameLimit の値です。 merge.renameLimit と diff.renameLimit の両方が指定されていない場合、現在のデフォルトは 7000 です。 この設定は、名前変更検出がオフの場合は効果がありません。

merge.renames

Gitが名前の変更を検出するかどうか。 「false」に設定すると、名前変更の検出が無効になります。 「true」に設定すると、基本的な名前変更の検出が有効になります。 デフォルトは diff.renames の値です。

merge.directoryRenames

Gitがディレクトリの名前変更を検出するかどうか。これは、履歴の一方の側でディレクトリが名前変更されたときに、もう一方の側で追加された新しいファイルがマージ時にどうなるのかに影響します。 merge.directoryRenames を false に設定すると、ディレクトリの名前変更の検出は無効になります。つまり、そのような新しいファイルは古いディレクトリに残されます。 true に設定すると、ディレクトリの名前変更検出が有効になり、そのような新しいファイルは新しいディレクトリに移動されることを意味します。 conflict に設定すると、そのようなパスに対して競合が報告されます。 merge.renames が false の場合、merge.directoryRenames は無視され、false として扱われます。 デフォルトは conflict です。

merge.renormalize

リポジトリ内のファイルの標準の表現が時間の経過とともに変更されたことをGitに伝えます(たとえば、以前はCRLF行末のレコードテキストファイルをコミットしていましたが、最近のファイルはLF行末を使用している)。 このようなリポジトリでは、Gitは、不必要な競合を減らすために、マージを実行する前に、コミットに記録されたデータを標準形式に変換できます。 詳細については、gitattributes(5) の「Merging branches with differing checkin/checkout attributes」(チェックイン/チェックアウト属性が異なるブランチのマージ)のセクションを参照してください。

merge.stat

マージの最後にORIG_HEADとマージ結果の間のdiffstatを出力するかどうか。 デフォルトではtrue。

merge.autoStash

trueに設定すると、操作を開始する前に一時的なstashエントリを自動的に作成し、操作の終了後に適用します。 これは、ダーティ作業ツリーでマージを実行できることを意味します。 ただし、注意して使用してください。マージが成功した後の最後のstashアプリケーションは、重要な競合を引き起こす可能性があります。 このオプションは、 git-merge(1)--no-autostash および --autostash オプションでオーバーライドできます。 デフォルトはfalseです。

merge.tool

git-mergetool(1) が使用するマージツールを制御します。 以下のリストは、有効な組み込み値を示しています。その他の値はカスタムマージツールとして扱われ、対応する mergetool.<tool>.cmd 変数が定義されている必要があります。

merge.guitool

-g/--gui フラグが指定されている場合に、 git-mergetool(1) が使用するマージツールを制御します。以下のリストは、有効な組み込み値を示しています。 その他の値はカスタムマージツールとして扱われ、対応する mergetool.<guitool>.cmd 変数が定義されている必要があります。

  • araxis

  • bc

  • bc3

  • bc4

  • codecompare

  • deltawalker

  • diffmerge

  • diffuse

  • ecmerge

  • emerge

  • examdiff

  • guiffy

  • gvimdiff

  • gvimdiff1

  • gvimdiff2

  • gvimdiff3

  • kdiff3

  • meld

  • nvimdiff

  • nvimdiff1

  • nvimdiff2

  • nvimdiff3

  • opendiff

  • p4merge

  • smerge

  • tkdiff

  • tortoisemerge

  • vimdiff

  • vimdiff1

  • vimdiff2

  • vimdiff3

  • winmerge

  • xxdiff

merge.verbosity

再帰的マージ戦略によって示される出力の量を制御します。 レベル0は、競合が検出された場合の最終エラーメッセージ以外は何も出力しません。 レベル1は競合のみを出力し、レベル2は競合とファイル変更を出力します。 レベル5以上はデバッグ情報を出力します。 デフォルトはレベル2です。 GIT_MERGE_VERBOSITY 環境変数でオーバーライドできます。

merge.<driver>.name

カスタムの低レベルマージドライバーの人間が読める名前を定義します。 詳細については、 gitattributes(5) を参照してください。

merge.<driver>.driver

カスタムの低レベルのマージドライバーを実装するコマンドを定義します。 詳細については、 gitattributes(5) を参照してください。

merge.<driver>.recursive

共通の祖先間で内部マージを実行するときに使用される低レベルのマージドライバーに名前を付けます。 詳細については、 gitattributes(5) を参照してください。

mergetool.<tool>.path

指定のツール(<tool>)のパスを上書きします。 これは、ツールがPATH上にない場合に役立ちます。

mergetool.<tool>.cmd

指定のマージツール(<tool>)を呼び出すコマンドを指定します。指定されたコマンドは、次の変数を使用してシェルで評価されます: BASE は、マージされるファイルの共通ベースを含む一時ファイルの名前です(使用可能な場合)。 LOCAL は、現在のブランチのファイルの内容を含む一時ファイルの名前です。 REMOTE は、マージされるブランチのファイルの内容を含む一時ファイルの名前です。 MERGED は、マージツールが正常なマージの結果を書き込むファイルの名前が含まれています。

mergetool.<tool>.hideResolved

ユーザーが特定のツール(<tool>)のグローバルな mergetool.hideResolved 値をオーバーライドできるようにします。 詳細については、 mergetool.hideResolved を参照してください。

mergetool.<tool>.trustExitCode

カスタムマージコマンドの場合、マージコマンドの終了コードを使用してマージが成功したかどうかを判断できるかどうかを指定します。 これがtrueで無い場合、マージターゲットファイルのタイムスタンプがチェックされ、ファイルが更新されている場合はマージが成功したと見なされます。そうでない場合、ユーザーはマージの成功を示すように求められます。

mergetool.meld.hasOutput

古いバージョンの meld--output オプションをサポートしていません。 Gitは、 meld --help の出力を調べることで、 meld--output をサポートしているかどうかを検出しようとします。 mergetool.meld.hasOutput を設定すると、Gitはこれらのチェックをスキップし、代わりに設定された値を使用します。 mergetool.meld.hasOutputtrue に設定すると、Gitは無条件に --output オプションを使用するようになり、 false--output の使用を回避します。

mergetool.meld.useAutoMerge

meld は --auto-merge が指定されると、競合しないすべての部分を自動的にマージし、競合する部分を強調表示して、ユーザーの決定を待ちます。 mergetool.meld.useAutoMerge を`true`に設定すると、Gitは --auto-merge オプションを meld で無条件に使用するようになります。 この値を auto に設定すると、gitは --auto-merge がサポートされているかどうかを検出し、使用可能な場合にのみ --auto-merge を使用します。 false の値はデフォルト値で、` --auto-merge` の使用を完全に回避します。

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

マージ解決プログラムを呼び出す前にプロンプトを表示します。

notes.mergeStrategy

ノートの競合を解決するときにデフォルトで選択するマージ戦略。 manual 、` ours`、 theirs、` union` 、cat_sort_uniq のいずれかである必要があります。 デフォルトは manual です。 各戦略の詳細については、 git-notes(1) の「NOTES MERGE STRATEGIES」セクションを参照してください。

notes.<name>.mergeStrategy

refs/notes/<name> にノートをマージするときに、どのマージ戦略を選択するか。 これは、より一般的な notes.mergeStrategy をオーバーライドします。 利用可能な戦略の詳細については、 git-notes(1) の「NOTES MERGE STRATEGIES」セクションを参照してください。

notes.displayRef

コミットメッセージを表示するときにノートを表示する、(完全修飾された)refname。 この変数の値はグロブ(glob)に設定できます。その場合、一致するすべての参照からのノートが表示されます。 この構成変数を複数回指定することもできます。 存在しない参照に対しては警告が発行されますが、どの参照とも一致しないグロブは黙って無視されます。

この設定は、 GIT_NOTES_DISPLAY_REF 環境変数でオーバーライドでき、環境変数はコロンで区切られたrefまたはグロブ(glob)のリストである必要があります。

core.notesRef の有効な値(GIT_NOTES_REFによってオーバーライドされる可能性があります)も、表示されるrefのリストに暗黙的に追加されます。

notes.rewrite.<command>

<command> (現在は amend または rebase)でコミットを書き換え、そして、この変数が true に設定されている場合、Gitはノートを元のコミットから書き換えられたコミットに自動的にコピーします。 デフォルトは true ですが、下記 notes.rewriteRef を参照してください。

notes.rewriteMode

書き換え時にノートをコピーする場合(notes.rewrite.<command> オプション参照)、ターゲットコミットにすでにノートがある場合の対処方法を決定します。 overwriteconcatenatecat_sort_uniqignore のいずれかである必要があります。 デフォルトは concatenate です。

この設定は、 GIT_NOTES_REWRITE_MODE 環境変数でオーバーライドできます。

notes.rewriteRef

書き換え中にノートをコピーする場合は、ノートをコピーする(完全修飾された)refを指定します。 refはグロブ(glob)である可能性があり、その場合、一致するすべてのrefのノートがコピーされます。 この構成を複数回指定することもできます。

デフォルト値はありません。 ノートの書き換えを有効にするには、この変数を構成する必要があります。 デフォルトのコミットノートの書き換えを有効にするには、これを refs/notes/commits に設定します。

この設定は、 GIT_NOTES_REWRITE_REF 環境変数でオーバーライドでき、環境変数はコロンで区切られたrefまたはグロブ(glob)のリストである必要があります。

pack.window

コマンドラインでウィンドウサイズが指定されていない場合に git-pack-objects(1) によって使用されるウィンドウのサイズ。デフォルトは10です。

pack.depth

コマンドラインで最大深度が指定されていない場合に git-pack-objects(1) によって使用される最大デルタ深度。デフォルトは50です。最大値は4095です。

pack.windowMemory

コマンドラインで制限が指定されていない場合に、パックウィンドウメモリの git-pack-objects(1) の各スレッドで消費されるメモリの最大サイズ。値には、「k」または「m」または「g」の接尾辞を付けることができます。未構成のまま(または明示的に0に設定する)にした場合、制限はありません。

pack.compression

パックファイル内のオブジェクトの圧縮レベルを示す整数 -1〜9。-1はzlibのデフォルトです。0は圧縮がないことを意味し、1〜9はさまざまな速度とサイズのトレードオフであり、9が最も低速です。設定されていない場合のデフォルトは core.compression です。 core.compression も設定されていない場合、デフォルトは -1 になります。これは、「速度と圧縮の間のデフォルトの妥協点(現在はレベル6と同等)」であるzlibのデフォルトです。

注意: 圧縮レベルを変更しても、既存のすべてのオブジェクトが自動的に再圧縮されるわけではないことに注意してください。 -F オプションを git-repack(1) に渡すことで、強制的に再圧縮できます。

pack.allowPackReuse

trueの場合、かつ、到達可能性ビットマップ(reachability bitmaps)が有効になっている場合、pack-objectsはビットマップ化されたパックファイルの一部をそのままで送信しようとします。これにより、フェッチを提供するためのメモリとCPUの使用量を減らすことができますが、送信するパックが少し大きくなる可能性があります。デフォルトはtrueです。

pack.island

デルタアイランド(delta islands)のセットを構成する拡張正規表現。詳細については、 git-pack-objects(1) の「DELTA ISLANDS」を参照してください。

pack.islandCore

オブジェクトを最初にパックする島名(island name)を指定します。 これにより、1つのパックの前に一種の疑似パックが作成されるため、指定の島のオブジェクトを、これらのオブジェクトを要求するユーザーに提供する必要のあるパックにコピーする速度が速くなることが期待されます。実際には、これは、指定された島が、リポジトリで最も一般的に複製される島に対応している可能性が高いことを意味します。 git-pack-objects(1) の「DELTA ISLANDS」も参照してください。

pack.deltaCacheSize

デルタをパックに書き出す前に、 git-pack-objects(1) でデルタをキャッシュするために使用されるバイト単位の最大メモリ。すべてのオブジェクトに最適なものが見つけたあとで、このキャッシュがあれば、最終的なデルタ結果を再計算する必要がないため、オブジェクトの書き込みフェーズを高速化できます。そのために使用されます。ただし、メモリが不足しているマシンで大規模なリポジトリを再パックして、特にこのキャッシュがシステムをスワップに追いやる場合、これによって悪影響を受ける可能性があります。値0は、制限がないことを意味します。このキャッシュを事実上無効にするために、最小サイズの1バイトを使用できます。デフォルトは256MiBです。

pack.deltaCacheLimit

git-pack-objects(1) でキャッシュされるデルタの最大サイズ。すべてのオブジェクトに最適なものが見つかった後、このキャッシュがあれば、最終的なデルタ結果を再計算する必要がないため、オブジェクトの書き込みフェーズを高速化します。そのために使用されます。デフォルトは1000です。最大値は65535です。

pack.threads

最適なデルタマッチングを検索するときに生成するスレッドの数を指定します。このためには git-pack-objects(1)をpthreadでコンパイルする必要があります。そうしないと、このオプションは無視され、警告が表示されます。 これは、マルチプロセッサマシンでのパッキング時間を短縮することを目的としています。ただし、デルタ検索ウィンドウに必要なメモリ量は、スレッド数で乗算されます。0を指定すると、GitはCPUの数を自動検出し、それに応じてスレッドの数を設定します。

pack.indexVersion

デフォルトのパックインデックスバージョンを指定します。有効な値は、1.5.2より前のバージョンで使用されていたレガシーパックインデックスの場合は1、4GBを超えるパックの機能と破損したパックの再パックに対する適切な保護を備えた新しいパックインデックスの場合は2です。バージョン2がデフォルトです。注意: 対応するパックが2GBを超える場合は常にバージョン2が適用され、この構成オプションは無視されることに注意してください。

バージョン2の *.idx ファイルを理解しない古いGitを使用している場合は、 *.pack ファイルと対応する *.idx ファイルの両方を反対側からコピーする非ネイティブプロトコル(例:http)を介してクローンを作成またはフェッチすると、古いバージョンのGitではアクセスできないリポジトリが提供される場合があります。けれども、 *.pack ファイルが2GBより小さい場合は、 *.pack に git-index-pack(1) を使用して、 *.idx ファイルを再生成できます。

pack.packSizeLimit

パックの最大サイズ。この設定は、再パック時にファイルへパッキングするときのみ影響します。つまり、 git:// プロトコルは影響を受けません。 git-repack(1)--max-pack-size オプションでオーバーライドできます。この制限に達すると、複数のパックファイルが作成されます。

注意: このオプションが役立つことはめったになく、(Gitはパックにまたがるデルタを保存しないため、)ディスク上の合計サイズが大きくなり、実行時のパフォーマンスが低下する可能性があることに注意してください(複数のパック内のオブジェクトルックアップは単一のパックで行うよりも遅く、到達可能性ビットマップなどの最適化は複数パックに対応できません)。

(たとえば、ファイルシステムが大きいファイルをサポートしていないため、)あなたが小さいパックファイルを使用してGitをバリバリと使う必要がある場合、このオプションが役立かもしれません。ただし、限られたサイズをサポートするメディア(たとえば、リポジトリ全体を保存できないリムーバブルメディア)を介してパックファイルを送信することが目標である場合は、単一の大きなパックファイルを作成し、一般的なマルチボリュームアーカイブツール(例えば Unix split )を使用して分割する方がよいでしょう。

許可される最小サイズは1MiBに制限されています。デフォルトの大きさは無制限です。 k または m または g の一般的な単位接尾辞がサポートされています。

pack.useBitmaps

trueの場合、(たとえば、フェッチ作業中のサーバー側で、)gitはstdoutにパックするときに(可能な場合は、)パックビットマップを使用します。デフォルトはtrueです。パックビットマップをデバッグしている場合を除いて、通常、これをオフにする必要はありません。

pack.useSparse

trueの場合、 gitは git pack-objects` で '--revs オプションが存在する場合、デフォルトで --sparse オプションを使用します。このアルゴリズムは、新しいオブジェクトを導入するパスに現れるツリーのみをウォークします。これは、小さな変更を送信するパックを計算するときに、パフォーマンスに大きなメリットをもたらす可能性があります。ただし、含まれているコミットに特定の種類の直接名前変更(direct renames)が含まれている場合は、パックファイルに追加のオブジェクトが追加される可能性があります。 デフォルトは true です。

pack.preferBitmapTips

ビットマップを受け取るコミットを選択するときは、「選択ウィンドウ」(selection window)の他のコミットよりも、この構成の任意の値の接尾辞である参照の先端にあるコミットを優先します。

注意: この設定を refs/foo に設定しても、 refs/foo/barrefs/foo/baz の先端のコミットが必ずしも選択されるわけではないことに注意してください。 これは、可変長の一連のウィンドウ内からビットマップに対してコミットが選択されるためです。

この構成の任意の値の接尾辞である参照の先端にあるコミットがウィンドウに表示された場合、そのウィンドウ内の他のコミットよりも即座に優先されます。

pack.writeBitmaps (deprecated)

これは、 repack.writeBitmaps の非推奨の同義語です。

pack.writeBitmapHashCache

trueの場合、gitはビットマップインデックスに「hash cache」(ハッシュキャッシュ)セクションを含めます(記述されている場合)。 このキャッシュは、gitのデルタヒューリスティックを供給するために使用でき、ビットマップオブジェクトと非ビットマップオブジェクト間のデルタを改善する可能性があります(たとえば、古いビットマップパックと最後のgc以降にプッシュされたオブジェクト間のフェッチを提供する場合)。欠点は、ディスクスペースのオブジェクトごとに4バイトを消費することです。 デフォルトはtrueです。

pack.writeReverseIndex

trueの場合、gitは、 git-fast-import(1) と バルクチェックインメカニズム(bulk checkin mechanism)を除く、すべての場所に書き込む新しいパックファイルごとに対応する .rev ファイル(参照: Documentation/technical/pack-format.txt)を書き込みます。デフォルトはfalseです。

pager.<cmd>

値がブール値の場合、ttyへの書き込み時に特定のGitサブコマンドの出力のページ付けをオンまたはオフにします。それ以外の場合は、 pager.<cmd> の値で指定されたページャーを使用してサブコマンドのページ付けをオンにします。コマンドラインで --paginate または --no-pager が指定されている場合、このオプションよりも優先されます。すべてのコマンドのページ付けを無効にするには、 core.pager または GIT_PAGERcat に設定します。

pretty.<name>

git-log(1)で 指定されている、 --pretty= 書式文字列のエイリアス。ここで定義されたエイリアスは、組み込みのpretty書式と同じように使用できます。 たとえば、 git config pretty.changelog "format:* %H %s" を実行すると、 git log --pretty=changelog の呼び出しは git log "--pretty=format:* %H %s" を実行するのと同じになります。注意: 組み込みフォーマットと同じ名前のエイリアスは黙って無視されることに注意してください。

protocol.allow

設定されている場合は、ポリシーを明示的に持たないすべてのプロトコルにユーザー定義のデフォルトポリシーを指定します(protocol.<name>.allow)。デフォルトでは、設定されていない場合、既知の安全なプロトコル(http、https、git、ssh、file)のデフォルトポリシーは「always」、既知の危険なプロトコル(ext)のデフォルトポリシーは「never」、その他の全てのプロトコルのデフォルトのポリシーは「user」です。サポートされているポリシーは以下です:

  • always - プロトコルは常に使用できます。

  • never - プロトコルを使用することはできません。

  • user - プロトコルは、 GIT_PROTOCOL_FROM_USER が設定されていないか、値が 1 の場合にのみ使用できます。このポリシーは、プロトコルをユーザーが直接使用できるようにしたいが、ユーザー入力なしの clone/fetch/push を実行するコマンドでは使用したくない場合(たとえば再帰的なsubmoduleの初期化の場合)、設定しなければなりません。

protocol.<name>.allow

clone/fetch/push コマンドでプロトコル <name> が使用するポリシーを設定します。 使用可能なポリシーについては、上記の「protocol.allow」を参照してください。

現在gitで使用されているプロトコル名はイカのとおりです:

  • file: 任意のローカルファイルベースのパス( file:// URL または ローカルパス を含む)

  • git: 直接TCP接続(または構成されている場合はプロキシ)を介した匿名のgitプロトコル

  • ssh: sshプロトコルの上で動くgitプロトコル( host:path 書式や ssh:// 等を含む)

  • http: httpプロトコルの上で動くgitプロトコル。「スマートhttp」と「ダムhttp」の両方です。両方を構成する場合は、個別に構成する必要があります。注意:これには https は含まれないことに注意してください。

  • 外部ヘルパーはそれらのプロトコルによる名前が付けられます(たとえば、 hg というプロトコルを指定したら git-remote-hg ヘルパーを許可します)

protocol.version

設定されている場合、クライアントは指定されたプロトコルバージョンを使用してサーバーとの通信を試みます。サーバーがサポートしていない場合、通信はバージョン0にフォールバックします。設定されていない場合、デフォルトは「2」です。 サポートされているバージョンは以下です:

  • 0 - 独自のワイヤープロトコル

  • 1 - サーバーからの初期応答にバージョン文字列が追加された独自のワイヤープロトコル。

  • 2 - wire protocol version 2

pull.ff

デフォルトでは、Gitは、現在のコミットの子孫であるコミットをマージするときに、追加のマージコミットを作成しません。 代わりに、現在のブランチの先端が早送り(fast-forward)されます。 false に設定すると、この変数はGitにそのような場合に追加のマージコミットを作成するように指示します(コマンドラインから --no-ff オプションを指定するのと同じです)。 only に設定すると、そのような早送り(fast-forward)マージのみが許可されます(コマンドラインから --ff-only オプションを指定するのと同じです)。 この設定は、プル時に merge.ff をオーバーライドします。

pull.rebase

trueの場合、 git pull の実行時にデフォルトのリモートからデフォルトのブランチをマージするのではなく、フェッチされたブランチの上にブランチをリベースします。 ブランチごとにこれを設定するには、 branch.<name>.rebase を参照してください。

merges (または単に m )の場合、 --rebase-merges オプションを git rebase に渡して、ローカルマージコミットがリベースに含まれるようにします(詳細については、 git-rebase(1) を参照してください)。

preserve (または単に pmerges を優先してこれは非推奨)の場合は、 --preserve-mergesgit rebase に渡して、ローカルでコミットされたマージコミットが git pull を実行してもフラット化されないようにします。

値が interactive (または単に i)の場合、リベースは対話モードで実行されます。

注意: これはおそらく危険な操作です。 あなたが影響を理解していない限り、使用しないでください (詳細については、 git-rebase(1) を参照してください)。

pull.octopus

複数のブランチを一度にプルするときに使用するデフォルトのマージ戦略。

pull.twohead

単一のブランチをプルするときに使用するデフォルトのマージ戦略。

push.default

(コマンドライン、構成、またはその他の場所で、)refspecが指定されていない場合に git push が実行するアクションを定義します。 特定の作業フローに適するさまざまな値があります。 たとえば、純粋に中央のワークフロー(つまり、フェッチ元がプッシュ先と等しい)では、 upstream がおそらく必要なものです。 可能な値は以下のとおりです:

  • nothing - refspecが指定されていない限り、何もプッシュ(エラー出力)しないでください。 これは主に、常に明示的にすることで間違いを避けたい人を対象としています。

  • current - 現在のブランチをプッシュして、受信側で同一の名前のブランチを更新します。 中央作業フローと非中央作業フローの両方で機能します。

  • upstream - 現在のブランチを、通常その変更が現在のブランチに統合されるブランチにプッシュバックします(これを @{upstream} と呼びます)。 このモードは、通常プルするのと同じリポジトリ(つまり中央ワークフロー)にプッシュする場合にのみ意味があります。

  • tracking - これは upstream の非推奨の同義語です。

  • simple - リモートで同一の名前の現在のブランチをプッシュします。

    あなたが一元化された作業フロー(あなたのプル元の同一のリポジトリにプッシュする、通常は origin )で作業している場合は、あなたは同一の名前でアップストリームブランチを構成する必要があります。

    このモードはGit2.0以降のデフォルトであり、初心者に適した最も安全なオプションです。

  • matching - 送信側受信側両方で同一の名前のすべてのブランチをプッシュします。 これにより、プッシュするリポジトリは、プッシュされるブランチのセットを記憶するようになります(たとえば、常に「maint」と「master」をプッシュし、他のブランチがない場合、プッシュするリポジトリには、これら2つのブランチがあり、ローカルの「maint」と「master」がそこにプッシュされます)。

    このモードを効果的に使用するには、 git push を実行する前に、あなたがプッシュしたい「すべてのブランチ」がプッシュされる準備ができていることを確認する必要があります。このモードの要点は、すべてのブランチを一度にプッシュできるようにすることです。通常、1つのブランチのみで作業を終了して結果をプッシュする場合、他のブランチは未完了ですので、このモードは適していません。 また、このモードは、共有中央リポジトリにプッシュするのには適していません。他の人がそこに新しいブランチを追加したり、コントロール外の既存のブランチの先端を更新したりする可能性があるためです。

    これは以前はデフォルトでしたが、Git 2.0以降ではそうではありません(simple が新しいデフォルトです)。

push.followTags

trueに設定されている場合、デフォルトで --follow-tags オプションを有効にします。 --no-follow-tags を指定することにより、プッシュ時にこの構成をオーバーライドできます。

push.gpgSign

ブール値、または文字列 if-asked に設定できます。 true値を指定すると、 --signed linkgit:git-push [1]に渡されたかのように、すべてのプッシュがGPG署名されます。 文字列 if-asked を指定し、サーバーがサポートしている場合は、 --signed=if-askedgit push に渡されたかのように、プッシュで署名されます。 誤った値は、優先度の低い構成ファイルの値を上書きする可能性があります。 明示的なコマンドラインオプションは、常にこの設定オプションを上書きします。

push.pushOption

コマンドラインから --push-option=<option> 引数が指定されていない場合、 git push はこの変数の各<value> が --push-option=<value> として指定されているかのように動作します。

これは複数値の変数であり、優先度の高い構成ファイル(リポジトリ内の .git/config など)で空の値を使用して、優先度の低い構成ファイル($HOME/.gitconfig など)から継承された値をクリアできます。

Example:

/etc/gitconfig
  push.pushoption = a
  push.pushoption = b

~/.gitconfig
  push.pushoption = c

repo/.git/config
  push.pushoption =
  push.pushoption = b

This will result in only b (a and c are cleared).
push.recurseSubmodules

プッシュされるリビジョンで使用されるすべてのサブモジュールコミットがリモートト追跡ブランチで利用可能であることを確認します。 値が check の場合、Gitは、プッシュされるリビジョンで変更されたすべてのサブモジュールコミットが、サブモジュールの少なくとも1つのリモートで使用可能であることを確認します。 コミットが欠落している場合、プッシュは中止(abort)され、ゼロ以外のステータスで終了します。 値が on-demand の場合、プッシュされるリビジョンで変更されたすべてのサブモジュールがプッシュされます。 on-demandで必要なすべてのリビジョンをプッシュできなかった場合も、中止(abort)され、ゼロ以外のステータスで終了します。 値が no の場合、プッシュ時にサブモジュールを無視するデフォルトの動作が保持されます。 --recurse-submodules=check|on-demand|no を指定することにより、プッシュ時にこの構成をオーバーライドできます。 設定されていない場合、 submodule.recurse が設定されていない限り、デフォルトで no が使用されます(この場合、 true 値は on-demand を意味します)。

push.useForceIfIncludes

「true」に設定すると、コマンドラインで git-push(1) のオプションとして --force-if-includes を指定するのと同じです。 プッシュ時に --no-force-if-includes を追加すると、この構成設定が上書きされます。

push.negotiate

「true」に設定されている場合は、クライアントとサーバーが共通のコミットを見つけようとするネゴシエーションの段階で送信されるパックファイルのサイズを縮小してみます。 「false」の場合、Gitはサーバーのref広告のみに依存して、共通のコミットを検索します。

rebase.backend

リベースに使用するデフォルトのバックエンド。 可能な選択肢は、「apply」または「merge」です。 将来、mergeバックエンドがapplyバックエンドの残りのすべての機能を取得した場合、この設定は使用されなくなる可能性があります。

rebase.stat

最後のリベース以降にアップストリームで変更されたもののdiffstatを表示するかどうか。デフォルトではFalseです。

rebase.autoSquash

trueに設定されている場合、デフォルトで --autosquash オプションを有効にします。

rebase.autoStash

trueに設定すると、操作を開始する前に一時的なstashエントリを自動的に作成し、操作の終了後に適用します。これは、ダーティワークツリーでリベースを実行できることを意味します。ただし、注意して使用してください。リベースが成功した後の最後のstashアプリケーションは、重要な競合を引き起こす可能性があります。このオプションは、 git-rebase(1)--no-autostash および --autostash オプションでオーバーライドできます。 デフォルトはfalseです。

rebase.missingCommitsCheck

「warn」に設定すると、 git rebase -i は、一部のコミットが削除された場合(たとえば、行が削除された場合)に警告を出力しますが、リベースは続行されます。 「error」に設定すると、前記の警告が出力され、リベースが停止(stop)します。 git rebase --edit-todo を使用して、エラーを修正できます。 「ignore」に設定すると、チェックは行われません。 警告やエラーなしにコミットをドロップするには、todoリストの drop コマンドを使用します。 デフォルトは「ignore」です。

rebase.instructionFormat

git-log(1) で指定されている、対話的リベース中にToDoリストに使用される書式文字列。書式では、自動的に長いコミットハッシュが書式の前に付加されます。

rebase.abbreviateCommands

trueに設定すると、 git rebase はtodoリストで省略コマンド名を使用し、以下のようになります:

        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 オプションを設定します。

receive.advertiseAtomic

デフォルトでは、git-receive-packはアトミックプッシュ機能(atomic push capability)をクライアントに公表(advertise)します。この機能を公表したくない場合は、この変数をfalseに設定してください。

receive.advertisePushOptions

trueに設定すると、git-receive-packはプッシュオプション機能(push options capability)をクライアントに公表(advertise)します。デフォルトではFalse。

receive.autogc

デフォルトでは、git-pushからデータを受信し、参照を更新した後、git-receive-packは git-gc --auto を実行します。 この変数をfalseに設定することで停止できます。

receive.certNonceSeed

この変数を文字列に設定すると、 git receive-packgit push --signed を受け入れ、その文字列を秘密鍵として使用してHMACによって保護された「nonce」を使用して検証します。

receive.certNonceSlop

git push --signed が、同じリポジトリにサービスを提供するreceive-packによって発行された「nonce」を含むプッシュ証明書をこの数秒以内に送信した場合、証明書で見つかった「nonce」をフックのために GIT_PUSH_CERT_NONCE にエクスポートします(receive-packが送信側に含めるように要求したものの代わりに)。 これにより、 pre-receivepost-receive でのチェックの記述が少し簡単になります。証明書を受け入れるかどうかを決定するために、nonce が何秒後に古くなるかを記録する環境変数 GIT_PUSH_CERT_NONCE_SLOP をチェックする代わりに、 GIT_PUSH_CERT_NONCE_STATUSOK であることだけをチェックすることができます。

receive.fsckObjects

trueに設定されている場合、git-receive-packは受信したすべてのオブジェクトをチェックします。 チェックされる内容については、 transfer.fsckObjects を参照してください。デフォルトはfalseです。設定されていない場合は、代わりに transfer.fsckObjects の値が使用されます。

receive.fsck.<msg-id>

fsck.<msg-id> のように機能しますが、 linkgit: git-fsck[1] の代わりに git-receive-pack(1) によって使用されます。詳細については、 fsck.<msg-id> の文書を参照してください。

receive.fsck.skipList

fsck.skipList のように機能しますが、 git-fsck(1) の代わりに git-receive-pack(1) によって使用されます。詳細については、 fsck.skipList の文書を参照してください。

receive.keepAlive

クライアントからパックを受信した後、パックの処理中に receive-pack が出力を生成せず(--quiet が指定されている場合)、一部のネットワークがTCP接続を切断する可能性があります。このオプションを設定すると、 receive-pack はこのフェーズで receive.keepAlive 秒の間データを送信しない場合、short keepalive packetを送信します。デフォルトは5秒です。キープアライブを完全に無効にするには、0に設定します。

receive.unpackLimit

プッシュで受信されるオブジェクトの数がこの制限を下回る場合、オブジェクトは緩いオブジェクト(loose object)ファイルに解凍されます。ただし、受信したオブジェクトの数がこの制限以上の場合、受信したパックは、欠落しているデルタベースを追加した後、パックとして保存されます。プッシュからパックを保存すると、特に低速のファイルシステムで、プッシュ操作をより速く完了することができます。 設定されていない場合は、代わりに transfer.unpackLimit の値が使用されます。

receive.maxInputSize

着信パックストリームのサイズがこの制限よりも大きい場合、パックファイルを受け入れる代わりに git-receive-pack がエラーになります。0に設定または設定されていない場合、サイズは無制限です。

receive.denyDeletes

trueに設定すると、git-receive-packはrefを削除するrefの更新を拒否します。これを使用して、プッシュによるそのような参照の削除を防ぎます。

receive.denyDeleteCurrent

trueに設定すると、git-receive-packは、非ベアリポジトリの現在チェックアウトされているブランチを削除するrefの更新を拒否します。

receive.denyCurrentBranch

trueまたは "refuse"(拒否)に設定すると、 git-receive-pack は、非ベアリポジトリの現在チェックアウトされているブランチへのrefの更新を拒否します。このようなプッシュは、HEADがインデックスおよび作業ツリーと同期しなくなるため、潜在的に危険です。"warn"(警告)に設定されている場合は、stderrへのそのようなプッシュの警告を出力しますが、プッシュを続行できるようにします。 falseまたは"ignore"(無視)に設定されている場合は、メッセージなしでそのようなプッシュを許可します。 デフォルトは"refuse"です。

別のオプションは"updateInstead"で、現在のブランチにプッシュすると作業ツリーが更新されます。このオプションは、インタラクティブsshを介して一方の側に簡単にアクセスできない場合に作業ディレクトリを同期することを目的としています(たとえば、ライブWebサイト。つまり作業ディレクトリがクリーンである必要があります)。 このモードは、VM内で開発して、さまざまなオペレーティングシステムでコードをテストおよび修正する場合にも役立ちます。

デフォルトでは、作業ツリーまたはインデックスにHEADとの違いがある場合、"updateInstead"はプッシュを拒否しますが、 push-to-checkout フックを使用してこれをカスタマイズできます。 githooks(5) を参照してください。

receive.denyNonFastForwards

trueに設定すると、git-receive-packは、fast-forwardではないrefの更新を拒否します。これを使用して、プッシュが強制されている場合でも、プッシュによるそのような更新を防ぎます。この構成変数は、共有リポジトリを初期化するときに設定されます。

receive.hideRefs

この変数は transfer.hideRefs と同じですが、 receive-pack にのみ適用されます(したがって、プッシュには影響しますが、フェッチには影響しません)。 git push によって非表示の参照を更新または削除しようとする試みは拒否されます。

receive.procReceiveRefs

これは、 receive-pack のコマンドに一致する参照プレフィックスを定義する複数値の変数(multi-valued variable)です。プレフィックスに一致するコマンドは、内部の execute_commands 関数ではなく、外部フック「proc-receive」によって実行されます。この変数が定義されていない場合、「proc-receive」フックは使用されず、すべてのコマンドは内部の execute_commands 関数によって実行されます。

たとえば、この変数が "refs/for" に設定されている場合、 "refs/for/master" などの参照にプッシュしても "refs/for/master" という名前の参照は作成・更新されませんが、 "proc-receive" フックを実行すれば直接プルリクエストを作成・更新できるはずです。

オプションの修飾子を値の先頭に指定して、特定のアクション(作成(a)、変更(m)、削除(d))のコマンドをフィルター処理できます。 ! を修飾子に含めて、参照プレフィックスエントリを無効にすることができます。 例えば以下のようにできます:

git config --system --add receive.procReceiveRefs ad:refs/heads
git config --system --add receive.procReceiveRefs !:refs/heads
receive.updateServerInfo

trueに設定すると、git-pushからデータを受信し、参照を更新した後、git-receive-packはgit-update-server-infoを実行します。

receive.shallowUpdate

trueに設定すると、新しい参照に新しいshallow rootsが必要になったときに .git/shallow を更新できます。それ以外の場合、それらの参照は拒否されます。

remote.pushDefault

デフォルトでプッシュするリモート。 すべてのブランチの branch.<name>.remote をオーバーライドし、特定のブランチの branch.<name>.pushRemote によってオーバーライドされます。

remote.<name>.url

リモートリポジトリのURL。 git-fetch(1) または git-push(1) を参照してください。

remote.<name>.pushurl

リモートリポジトリのプッシュURL。 git-push(1) を参照してください。

remote.<name>.proxy

curl(httpとhttpsとftp)を必要とするリモートの場合、そのリモートに使用するプロキシへのURL。 そのリモートのプロキシを無効にするには、空の文字列に設定します。

remote.<name>.proxyAuthMethod

curl(httpとhttpsとftp)を必要とするリモートの場合、使用中のプロキシ(おそらく remote.<name>.proxy で設定)に対して認証するために使用するメソッド。 http.proxyAuthMethod を参照してください。

remote.<name>.fetch

git-fetch(1) のデフォルトの「refspec」セット。 git-fetch(1) を参照してください。

remote.<name>.push

git-push(1) のデフォルトの「refspec」セット。 git-push(1) を参照してください。

remote.<name>.mirror

trueの場合、このリモートにプッシュすると、コマンドラインで --mirror オプションが指定されたかのように自動的に振る舞います。

remote.<name>.skipDefaultUpdate

trueの場合、 git-fetch(1) または git-remote(1)update サブコマンドを使用して更新すると、このリモートはデフォルトでスキップされます。

remote.<name>.skipFetchAll

trueの場合、 git-fetch(1) または git-remote(1)update サブコマンドを使用して更新すると、このリモートはデフォルトでスキップされます。

remote.<name>.receivepack

プッシュ時にリモート側で実行するデフォルトのプログラム。 git-push(1) のオプション --receive-pack を参照してください。

remote.<name>.uploadpack

フェッチ時にリモート側で実行するデフォルトのプログラム。 git-fetch-pack(1) のオプション --upload-pack を参照してください。

remote.<name>.tagOpt

この値を --no-tags に設定すると、リモート<name>からフェッチするときの自動タグ追跡が無効になります。 --tags に設定すると、リモートブランチヘッドから到達できない場合でも、リモート<name>からすべてのタグがフェッチされます。 これらのフラグを直接 git-fetch(1) に渡すと、この設定を上書きできます。 git-fetch(1) のオプション --tags および --no-tags を参照してください。

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 および git-fetch(1) の「PRUNING」セクションも参照してください。

remote.<name>.promisor

trueに設定すると、このリモートはプロミザー(promisor)オブジェクトをフェッチするために使用されます。

remote.<name>.partialclonefilter

このプロミザー(promisor)リモートからフェッチするときに適用されるフィルター。

remotes.<group>

git remote update <group> によってフェッチされるremoteのリスト。 git-remote(1) を参照してください。

repack.useDeltaBaseOffset

デフォルトでは、 git-repack(1) はデルタベースオフセットを使用するパックを作成します。 あなたのリポジトリを、バージョン1.4.4より古いGitと直接、またはhttpなどのバカ(dumb)プロトコルを介して共有する必要がある場合は、このオプションを false に設定して再パックする必要があります。 ネイティブプロトコルを介した古いバージョンのGitからのアクセスは、このオプションの影響を受けません。

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はすべてのオブジェクトをディスクにパックするときにビットマップインデックスを書き込みます(たとえば、 git repack -a が実行される場合)。 このインデックスは、クローンとフェッチ用に作成された後続のパックの「オブジェクトのカウント」フェーズを高速化できますが、ディスクスペースと最初の再パックに余分な時間がかかります。 複数のパックファイルが作成されている場合、これは効果がありません。 ベア(bare)リポジトリではデフォルトでtrueになり、それ以外の場合はfalseになります。

rerere.autoUpdate

trueに設定すると、 git-rerere は、以前に記録された解決策を使用して競合をクリーンに解決した後、結果のコンテンツでインデックスを更新します。 デフォルトはfalseです。

rerere.enabled

解決された競合の記録をアクティブにして、同じ競合ハンクが再度発生した場合に自動的に解決できるようにします。 デフォルトでは、 $GIT_DIR の下に rr-cache ディレクトリがある(例えば rerere が以前にリポジトリで使用されていた)場合、 git-rerere(1) が有効になります。

reset.quiet

trueに設定すると、 git reset はデフォルトで --quiet オプションになります。

sendemail.identity

構成ID。 指定すると、 sendemail.<identity> サブセクションの値が sendemail セクションの値よりも優先されます。 デフォルトのIDは、 `sendemail.identity`の値です。

sendemail.smtpEncryption

説明については、 git-send-email(1) を参照してください。 注意: この設定は identity メカニズムの対象ではないことに注意してください。

sendemail.smtpsslcertpath

ca-certificatesへのパス(ディレクトリまたは単一ファイルのどちらか)。 証明書の検証を無効にするには、空の文字列に設定します。

sendemail.<identity>.*

以下の sendemail.* パラメータのID固有のバージョン。コマンドラインまたは sendemail.identity のいずれかを使用して、このIDが選択された場合のパラメータよりも優先されます。

sendemail.aliasesFile
sendemail.aliasFileType
sendemail.annotate
sendemail.bcc
sendemail.cc
sendemail.ccCmd
sendemail.chainReplyTo
sendemail.confirm
sendemail.envelopeSender
sendemail.from
sendemail.multiEdit
sendemail.signedoffbycc
sendemail.smtpPass
sendemail.suppresscc
sendemail.suppressFrom
sendemail.to
sendemail.tocmd
sendemail.smtpDomain
sendemail.smtpServer
sendemail.smtpServerPort
sendemail.smtpServerOption
sendemail.smtpUser
sendemail.thread
sendemail.transferEncoding
sendemail.validate
sendemail.xmailer

説明については、 git-send-email(1) を参照してください。

sendemail.signedoffcc (非推奨)

sendemail.signedoffbycc の非推奨のエイリアス。

sendemail.smtpBatchSize

接続ごとに送信されるメッセージの数。その後、再ログインが発生します。 値が0または未定義の場合、すべてのメッセージを1つの接続で送信します。 git-send-email(1)--batch-size オプションも参照してください。

sendemail.smtpReloginDelay

SMTPサーバーに再接続する前に指定の秒数待機します。 git-send-email(1)--relogin-delay オプションも参照してください。

sendemail.forbidSendmailVariables

一般的な設定ミスを回避するために、 git-send-email(1) は、 sendmail の設定オプションが存在する場合、警告とともに中止します。 チェックをバイパスするには、この変数を設定します。

sequence.editor

リベース命令ファイル(rebase instruction file)を編集するために git rebase -i によって使用されるテキストエディタ。この値は、使用時にシェルによって解釈されることを意図しています。 これは、 GIT_SEQUENCE_EDITOR 環境変数によってオーバーライドできます。構成されていない場合は、代わりにデフォルトのコミットメッセージエディタが使用されます。

showBranch.default

git-show-branch(1) のデフォルトのブランチセット。 git-show-branch(1) を参照してください。

splitIndex.maxPercentChange

分割インデックス機能を使用する場合、これは、新しい共有インデックスが書き込まれる前の、分割インデックスと共有インデックスの両方のエントリの総数と比較した、分割インデックスに含めることができるエントリの割合を指定します。 値は0〜100の間である必要があります。 値が0の場合、新しい共有インデックスが常に書き込まれ、100の場合、新しい共有インデックスが書き込まれることはありません。 デフォルトの値は20であるため、分割インデックスのエントリ数がエントリの総数の20%を超える場合は、新しい共有インデックスが書き込まれます。 git-update-index(1) を参照してください。

splitIndex.sharedIndexExpire

分割インデックス機能を使用すると、この変数が指定する時間以降に変更されなかった共有インデックスファイルは、新しい共有インデックスファイルが作成されるときに削除されます。 値 now はすべてのエントリをすぐに期限切れにし、 never は期限切れを完全に抑制します。 デフォルト値は 2.weeks.ago です。 共有インデックスファイルは、それに基づいて新しい分割インデックスファイルが作成されるか、そこから読み取られるたびに、(有効期限について)変更されたと見なされることに注意してください。 git-update-index(1) を参照してください。

ssh.variant

デフォルトでは、Gitは設定されたSSHコマンドのベース名(環境変数 GIT_SSH または環境変数 GIT_SSH_COMMAND または構成設定 core.sshCommand を使用して設定)に基づいて使用するコマンドライン引数を決定します。ベース名が認識されない場合、Gitは最初に -G (print configuration)オプションを使用して構成済みのSSHコマンドを呼び出し、その後、(成功した場合、)OpenSSHオプションを使用するか、(失敗した場合、)hostおよびremoteコマンド以外のオプションを使用しないことで、OpenSSHオプションのサポートを検出しようとします。

構成変数 ssh.variant は、この検出をオーバーライドするように設定できます。有効な値は、 ssh (OpenSSHオプションを使用する場合)、 plinkputtytortoiseplinksimple (hostおよびremoteコマンド以外のオプションを持っていません)、です。 デフォルトの自動検出は、値 auto を使用して明示的に要求できます。また、これ以外の値は ssh として扱われます。この設定は、環境変数 GIT_SSH_VARIANT を介してオーバーライドすることもできます。

各派生で使用されている現在のコマンドラインパラメータは以下のとおりです:

  • ssh - [-p port] [-4] [-6] [-o option] [username@]host command

  • simple - [username@]host command

  • plink or putty - [-P port] [-4] [-6] [username@]host command

  • tortoiseplink - [-P port] [-4] [-6] -batch [username@]host command

simple 派生を除き、コマンドラインパラメータはgitが新しい機能を取得するにつれて変更される可能性があります。

status.relativePaths

デフォルトでは、 git-status(1) は現在のディレクトリからの相対パスを表示します。 この変数を false に設定すると、リポジトリルートを基準にしたパスが表示されます(これはv1.5.4より前のGitのデフォルトでした)。

status.short

git-status(1) でデフォルトで --short を有効にするには、trueに設定します。 オプション` --no-short` は、この変数よりも優先されます。

status.branch

git-status(1) でデフォルトで --branch を有効にするには、trueに設定します。 オプション --no-branch は、この変数よりも優先されます。

status.aheadBehind

非磁器コマンドステータス形式(non-porcelain status formats)の git-status(1) で、デフォルトで --ahead-behind を有効にするにはtrueに設定し、 --no-ahead-behind を有効にするにはfalseに設定します。 デフォルトはtrueです。

status.displayCommentPrefix

trueに設定すると、 git-status(1) は各出力行の前にコメントプレフィックスを挿入します(core.commentChar で始まります。つまりデフォルトでは # です)。 これは、Git 1.8.4以前の git-status(1) の動作でした。 デフォルトはfalseです。

status.renameLimit

git-status(1) および git-commit(1) で名前変更の検出を実行するときに考慮するファイルの数。 デフォルトは diff.renameLimit の値です。

status.renames

Gitが git-status(1)git-commit(1) で名前の変更を検出するかどうかとその方法。 false に設定すると、名前変更の検出が無効になります。 true に設定すると、基本的な名前変更の検出が有効になります。 copies または copy に設定されている場合、Gitはコピーも検出します。 デフォルトは diff.renames の値です。

status.showStash

trueに設定すると、 git-status(1) は現在stashされているエントリの数を表示します。 デフォルトはfalseです。

status.showUntrackedFiles

デフォルトでは、 git-status(1)git-commit(1) は、現在Gitによって追跡されていないファイルを表示します。 追跡されていないファイルのみを含むディレクトリは、ディレクトリ名のみで表示されます。 追跡されていないファイルを表示するということは、Gitがリポジトリ全体のすべてのファイルを lstat() する必要があることを意味します。これは、一部のシステムでは低速になる可能性があります。 したがって、この変数は、コマンドが追跡されていないファイルを表示する方法を制御します。 可能な値は以下のとおりです:

  • no - 追跡していないファイルを表示しない。

  • normal - 追跡していないファイルとディレクトリを表示

  • all - 追跡されていないディレクトリ内の個々のファイルも表示。

この変数が指定されていない場合、デフォルトで normal になります。 この変数は、 git-status(1) および git-commit(1)-u|--untracked-files オプションでオーバーライドできます。

status.submoduleSummary

デフォルトはfalseです。 これがゼロ以外の数値、またはtrue(-1または無制限と同じ)に設定されている場合、サブモジュールの要約が有効になり、変更されたサブモジュールのコミットの要約が表示されます(git-submodule(1)--summary-limit オプションを参照してください)。 diff.ignoreSubmodulesall に設定されている場合、または submodule.<name>.ignore=all であるサブモジュールに対してのみ、要約出力コマンドが抑制されることに注意してください。 そのルールの唯一の例外は、statusとcommitが、ステージされたサブモジュールの変更を表示することです。 無視されたサブモジュールの概要も表示するには、 --ignore-submodules=dirty コマンドラインオプションまたは git submodule summary コマンドを使用できます。これは同様の出力を表示しますが、これらの設定を尊重しません。

stash.useBuiltin

未使用の構成変数。 Gitバージョン2.22から2.26で、stashのレガシーシェルスクリプト実装を有効にするための緊急避難口(escape hatch)として使用されていました。 現在はC言語での組み込みの書き換えが常に使用されています。 これを設定すると警告が表示され、これを設定しても何も起こらないことをユーザーに警告します。

stash.showIncludeUntracked

これがtrueに設定されている場合、 git stash show コマンドはstashエントリの追跡されていないファイルを表示します。 デフォルトはfalseです。 git-stash(1) の showコマンドの説明を参照してください。

stash.showPatch

これがtrueに設定されている場合、オプションのない git stash show コマンドは、パッチ形式でstashエントリを表示します。 デフォルトはfalseです。 git-stash(1)の showコマンドの説明を参照してください。

stash.showStat

これがtrueに設定されている場合、オプションのない git stash show コマンドは、stashエントリのdiffstatを表示します。 デフォルトはtrueです。 git-stash(1) の showコマンドの説明を参照してください。

submodule.<name>.url

サブモジュールのURL。 この変数は、 git submodule init を介して .gitmodules ファイルから git config にコピーされます。 ユーザーは、 git submodule update を介してサブモジュールを取得する前に、構成されたURLを変更できます。 submodule.<name>.activesubmodule.active も設定されていない場合、この変数の存在は、サブモジュールがgitコマンドに関係するかどうかを示すためのフォールバックとして使用されます。 詳細については、 git-submodule(1)および gitmodules(5) を参照してください。

submodule.<name>.update

影響を受ける唯一のコマンドである git submodule update によってサブモジュールが更新される方法。 git checkout --recurse-submodules などの他のコマンドは影響を受けません。 git submodule がサブモジュールと対話する唯一のコマンドであった場合、これは歴史的な理由で存在します。 submodule.active`や `pull.rebase などの設定はより具体的です。 これは、gitmodules(5) ファイルから git submodule init によって入力されます。 git-submodule(1) のupdateコマンドの説明を参照してください。

submodule.<name>.branch

git submodule update --remote によって使用されるサブモジュールのリモートブランチ名。 このオプションを設定すると、 .gitmodules ファイルにある値が上書きされます。 詳細については、 git-submodule(1) および gitmodules(5) を参照してください。

submodule.<name>.fetchRecurseSubmodules

このオプションは、このサブモジュールの再帰的フェッチを制御するために使用できます。 --[no-]recurse-submodules コマンドラインオプションを使用して git fetchgit pull をオーバーライドすることでオーバーライドできます。 この設定は、 gitmodules(5) ファイルの設定を上書きします。

submodule.<name>.ignore

どのような状況で git status とdiffファミリーがサブモジュールを変更済みとして表示するかを定義します。 all に設定すると、変更されたとは見なされません(ただし、ステータスの出力に表示され、ステージングされるとコミットされます)。 dirty は、サブモジュールの作業ツリーに対するすべての変更を無視し、差異のみを取ります。 サブモジュールのHEADと、スーパープロジェクトに記録されたコミットの間を考慮に入れます。 untracked はさらに、作業ツリー内の変更された追跡ファイルを持つサブモジュールを表示させます。 none (設定されていない場合のデフォルト)を使用すると、作業ツリーに追跡されていないファイルが変更されたサブモジュールも表示されます。 この設定は、このサブモジュールの .gitmodules`で行われた設定を上書きします。両方の設定は、 `--ignore-submodules オプションを使用してコマンドラインで上書きできます。 git submodule コマンドは、この設定の影響を受けません。

submodule.<name>.active

サブモジュールがgitコマンドに関係するかどうかを示すブール値。 この構成オプションは、 submodule.active 構成オプションよりも優先されます。 詳細については、 gitsubmodules(7) を参照してください。

submodule.active

サブモジュールが git コマンドの対象かどうかを判断するためにサブモジュールのパスと照合するために使用される pathspec を含む繰り返しフィールド。詳細は gitsubmodules(7) を参照してください。

submodule.recurse

コマンドがデフォルトで --recurse-submodules オプションを有効にするかどうかを示すブール値。 clone と`ls-files` を除く、このオプションをサポートするすべてのコマンド(checkoutfetchgreppullpushread-treeresetrestoreswitch)に適用されます。 デフォルトはfalseです。 trueに設定すると、 --no-recurse-submodules オプションを使用して非アクティブ化できます。 このオプションがない一部のGitコマンドは、 submodule.recurse の影響を受ける上記のコマンドの一部を呼び出す可能性があることに注意してください。 たとえば、 git remote updategit fetch を呼び出しますが、 --no-recurse-submodules オプションはありません。 これらのコマンドの回避策は、 git -c submodule.recurse=0 を使用して構成値を一時的に変更することです。

submodule.fetchJobs

同時に フェッチ/クローン されるサブモジュールの数を指定します。 正の整数を使用すると、その数までのサブモジュールを並列にフェッチできます。 値0は、適切なデフォルトを提供します。 設定されていない場合、デフォルトで1になります。

submodule.alternateLocation

サブモジュールがcloneされるときに、サブモジュールがalternateを取得する方法を指定します。 可能な値は nosuperproject です。 デフォルトでは、参照を追加しない no が想定されています。 値が superproject に設定されている場合、cloneされるサブモジュールは、スーパープロジェクトのalternates locationを基準にしてalternates locationを計算します。

submodule.alternateErrorStrategy

submodule.alternateLocation を介して計算されたサブモジュールのalternateでエラーを処理する方法を指定します。 可能な値は ignoreinfodie です。デフォルトは die です。 ignore または info に設定されていて、計算されたalternateにエラーがある場合、alternateが指定されていないかのようにクローンが進行することに注意してください。

tag.forceSignAnnotated

作成された注釈付きタグをGPG署名するかどうかを指定するブール値。 コマンドラインで --annotate が指定されている場合、このオプションよりも優先されます。

tag.sort

この変数は、 git-tag(1) によって表示されるときのタグの並べ替え順序を制御します。 --sort=<value> オプションが指定されていない場合、この変数の値がデフォルトとして使用されます。

tag.gpgSign

すべてのタグをGPG署名するかどうかを指定するブール値。 自動スクリプトで実行しているときにこのオプションを使用すると、多数のタグが署名される可能性があります。 したがって、あなたは、エージェントを使用して、gpgパスフレーズを毎回入力しないようにするのが便利です。 このオプションは、 -u<keyid> または --local-user=<keyid> オプションによって有効にされるタグ署名の動作には影響しないことに注意してください。

tar.umask

この変数は、tarアーカイブエントリの許可ビットを制限するために使用できます。デフォルトは0002で、ワールド書き込みビット(world write bit)をオフにします。 特別な値 "user" は、アーカイブユーザーのumaskが代わりに使用されることを示します。 umask(2) および git-archive(1) を参照してください。

trace2構成設定は、システムおよびグローバル構成ファイルからのみ読み取られます。 リポジトリのローカルおよびワークツリー構成ファイルと -c コマンドライン引数は尊重されません。

trace2.normalTarget

この変数は、通常のターゲット(normal target)宛先を制御します。 GIT_TRACE2 環境変数によってオーバーライドされる可能性があります。

trace2.perfTarget

この変数は、パフォーマンスターゲットの宛先を制御します。 GIT_TRACE2_PERF 環境変数によってオーバーライドされる可能性があります。

trace2.eventTarget

この変数は、イベントターゲットの宛先を制御します。 GIT_TRACE2_EVENT 環境変数によってオーバーライドされる可能性があります。

  • 0 or false - ターゲットを無効にします。

  • 1 or true - STDERR に書き出します。

  • [2-9] - すでに開いているファイル・デスクリプターに書き出します。

  • <absolute-pathname> - appendモードでファイルに書き込みます。ターゲットがすでに存在し、ディレクトリである場合、トレースは指定のディレクトリの下のファイル(プロセスごとに1つ)に書き込まれます。

  • af_unix:[<socket_type>:]<absolute-pathname> - Unixドメインソケットに書き出します(それらをサポートするプラットフォーム上であれば)。ソケットタイプは stream または dgram のいずれかです。省略した場合、Gitは両方を試します。

trace2.normalBrief

ブール値。 trueの場合、 timefilenameline フィールドは通常の出力(normal output)から省略されます。 GIT_TRACE2_BRIEF 環境変数によってオーバーライドされる可能性があります。 デフォルトはfalseです。

trace2.perfBrief

ブール値。 trueの場合、 timefilenameline フィールドはPERF出力から省略されます。 GIT_TRACE2_PERF_BRIEF 環境変数によってオーバーライドされる可能性があります。 デフォルトはfalseです。

trace2.eventBrief

ブール値。 trueの場合、 timefilenameline フィールドはイベント出力から省略されます。 GIT_TRACE2_EVENT_BRIEF 環境変数によってオーバーライドされる可能性があります。 デフォルトはfalseです。

trace2.eventNesting

整数。 イベント出力でネストされた領域(region)の必要な深さを指定します。この値より深い領域は省略されます。 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構成ファイルの場所をリストするイベントが含まれます。 GIT_TRACE2_ENV_VARS 環境変数によってオーバーライドされる可能性があります。 デフォルトでは設定されていません。

trace2.destinationDebug

ブール値。 trueの場合、トレースターゲットの宛先を書き込み用に開くことができない場合、Gitはエラーメッセージを出力します。 デフォルトでは、これらのエラーは抑制され、トレースは黙って無効になっています。 GIT_TRACE2_DST_DEBUG 環境変数によってオーバーライドされる可能性があります。

trace2.maxFiles

整数。 トレースファイルをターゲットディレクトリに書き込むとき、この数のファイルを超える場合は、追加のトレースを書き込まないでください。 代わりに、このディレクトリへのそれ以上のトレースをブロックする番兵ファイル(sentinel file)を作成します。 デフォルトは0で、このチェックを無効にします。

transfer.fsckObjects

fetch.fsckObjects または receive.fsckObjects が設定されていない場合、代わりにこの変数の値が使用されます。デフォルトはfalseです。

設定すると、不正な形式のオブジェクトまたは存在しないオブジェクトへのリンクの場合、フェッチまたは受信は中止されます。 さらに、レガシー問題(fsck.<msg-id> を参照)を含む、 .GIT ディレクトリや悪意のある .gitmodules ファイルの存在などの潜在的なセキュリティの問題(詳細については、v2.2.1およびv2.17.1のリリースノートを参照してください)など、他のさまざまな問題がチェックされます。 その他の健全性とセキュリティのチェックが、将来のリリースで追加される可能性があります。

受信側では、fsckObjects に障害が発生すると、これらのオブジェクトに到達できなくなります。 git-receive-pack(1) の「QUARANTINE ENVIRONMENT」を参照してください。 一方、フェッチ側では、不正な形式のオブジェクトはリポジトリで参照されない(unreferenced)ままになります。

fetch.fsckObjects 実装は隔離されていない(non-quarantine nature)ため、 receive.fsckObjects のようにオブジェクトストアをクリーンな状態に保つことはできません。

オブジェクトが解凍されると、オブジェクトストアに書き込まれるため、「フェッチ」が失敗したにもかかわらず、悪意のあるオブジェクトが導入される場合があります。オブジェクトストアにすでに書き込まれているオブジェクトではなく、新しい着信オブジェクトのみがチェックされるため、後続の「フェッチ」が成功するだけです。 この振る舞いの違いは信頼されるべきではありません。将来的には、そのようなオブジェクトは「フェッチ」のために隔離される可能性があります。

今のところ、「プッシュ」と同じ保護が必要な場合、疑り深い人(paranoid)は検疫環境をエミュレートする方法を見つける必要があります。 例えば、内部ミラーの場合、2つのステップでミラーリングを実行します。信頼できないオブジェクトをフェッチするために1ステップ、そして次に、別の内部リポジトリに「プッシュ」(隔離を使用します)を実行する2ステップ目です。内部クライアントにこのプッシュ先リポジトリを消費させ、または、内部フェッチを禁止し、完全な fsck が実行された場合にのみ許可します(その間に新しいフェッチは発生しません)。

transfer.hideRefs

文字列 receive-packupload-pack は、最初の広告から除外するrefを決定するために使用します。 複数のプレフィックス文字列を指定するには、複数の定義を使用します。 この変数の値にリストされている階層の下にあるrefは除外され、 git push または git fetch に応答するときに非表示になります。 この構成のプログラム固有のバージョンについては、 receive.hideRefs および uploadpack.hideRefs を参照してください。

あなたは ref名の前に ! を含めてエントリを無効にし、以前のエントリで非表示としてマークされていた場合でも、明示的に公開することもできます。 複数の非表示ref値がある場合、後のエントリが前のエントリを上書きします(そして、より具体的な構成ファイルのエントリは、より具体的でないものを上書きします)。

名前空間が使用されている場合、名前空間プレフィックスは、 transfer.hiderefs パターンと照合される前に、各参照から削除されます。 削除する前に参照を一致させるには、参照名の前に ^ を追加します。 !^ を組み合わせる場合は、最初に ! を指定する必要があります。

たとえば、 refs/heads/mastertransfer.hideRefs で指定され、現在の名前空間が foo の場合、 refs/namespaces/foo/refs/heads/master は広告から省略されます。 uploadpack.allowRefInWant が設定されている場合、 upload-pack は、プロトコルバージョン2の fetch コマンドの want-ref refs/heads/master で、 refs/namespaces/foo/refs/heads/master が存在しないかのように扱います。 一方、 receive-pack`は、その名前(いわゆる `.have 行)を指定せずに、refが指しているオブジェクトIDを広告します。

refを非表示にしても、 gitnamespaces(7)のマニュアルページの「SECURITY」セクションで説明されている手法を使用して、クライアントがターゲットオブジェクトを盗むことができる場合があります。よって、プライベートデータは別のリポジトリに保持するのが最良です。

transfer.unpackLimit

fetch.unpackLimit または receive.unpackLimit が設定されていない場合、代わりにこの変数の値が使用されます。 デフォルト値は100です。

transfer.advertiseSID

ブール値。 trueの場合、クライアントプロセスとサーバープロセスは、一意のセッションIDをリモートの対応するプロセスに広告します。 デフォルトはfalseです。

uploadarchive.allowUnreachable

trueの場合、クライアントが git archive --remote を使用して、ref先端から到達可能かどうかに関係なく、任意のツリーを要求できるようにします。詳細については、 git-upload-archive(1)の「SECURITY」セクションの説明を参照してください。デフォルトは false です。

uploadpack.hideRefs

この変数は transfer.hideRefs と同じですが、 upload-pack にのみ適用されます(したがって、プッシュではなくフェッチにのみ影響します)。 git fetch で隠しref(hidden ref)をフェッチしようとすると失敗します。 uploadpack.allowTipSHA1InWant も参照してください。

uploadpack.allowTipSHA1InWant

uploadpack.hideRefs が有効な場合、 upload-pack が非表示の参照の先端にあるオブジェクトを要求するフェッチ要求を受け入れることを許可します(デフォルトでは、そのような要求は拒否されます)。 uploadpack.hideRefs も参照してください。 これが false であっても、クライアントは、 gitnamespaces(7) のマニュアルページの「SECURITY」セクションで説明されている手法を使用してオブジェクトを盗むことができる場合があります。プライベートデータを別のリポジトリに保持することをお勧めします。

uploadpack.allowReachableSHA1InWant

upload-pack が、任意の参照先端から到達可能なオブジェクトを要求するフェッチ要求を受け入れることを許可します。 ただし、オブジェクトの到達可能性の計算には計算コストがかかることに注意してください。 デフォルトは false です。 これが false であっても、クライアントは、 gitnamespaces(7) のマニュアルページの「SECURITY」セクションで説明されている手法を使用してオブジェクトを盗むことができる場合があります。 プライベートデータを別のリポジトリに保持することをお勧めします。

uploadpack.allowAnySHA1InWant

upload-pack が、オブジェクトを要求するフェッチ要求を受け入れることを許可します。 デフォルトは false です。

uploadpack.keepAlive

upload-packpack-objects を開始したとき、pack-objects がパックを準備している間は黙っている期間があるかもしれません。 通常は進行状況情報を出力しますが、フェッチに --quiet を使用した場合、 pack-objects はパックデータが開始するまで何も出力しません。 一部のクライアントとネットワークは、サーバーがハングしてあきらめていると見なす場合があります。 このオプションを設定すると、 upload-packuploadpack.keepAlive 秒ごとに空のキープアライブパケットを送信するように指示されます。 このオプションを0に設定すると、キープアライブパケットが完全に無効になります。 デフォルトは5秒です。

uploadpack.packObjectsHook

このオプションが設定されている場合、 upload-pack がクライアントのパックファイルを作成するために git pack-objects を実行しようとすると、代わりにこのシェルコマンドが実行されます。 pack-objects コマンドとそれが実行するであろう引数(最初の git pack-objects を含む)がシェルコマンドに追加されます。 フックのstdinとstdoutは、 pack-objects 自体が実行されたかのように扱われます。 つまり、 upload-pack は、 pack-objects を対象とした入力をフックに送り、stdoutで完成したpackfileを期待します。

注意: この構成変数は、リポジトリレベルの構成で見られる場合は無視されることに注意してください(これは、信頼できないリポジトリからのフェッチに対する安全対策です)。

uploadpack.allowFilter

このオプションが設定されている場合、 upload-pack は部分クローン(partial clone)および部分フェッチオブジェクト(partial fetch object)のフィルタリングをサポートします。

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

<n>uploadpackfilter.tree.maxDepth の値以下の場合にのみ、 --filter=tree:<n> を許可します。 設定されている場合、この構成変数がすでに設定されていない限り、これは uploadpackfilter.tree.allow=true も意味します。 設定されていない場合は効果がありません。

uploadpack.allowRefInWant

このオプションが設定されている場合、 upload-pack はプロトコルバージョン2の fetch コマンドの ref-in-want 機能をサポートします。 この機能は、レプリケーションの遅延のために、refが指すOIDについて同じビューを持たない可能性がある負荷分散サーバーの利益を目的としています。

url.<base>.insteadOf

この値で始まるURLは、代わりに<base>で始まるように書き換えられます。 あるサイトが多数のリポジトリを提供し、それらを複数のアクセス方法で提供しており、一部のユーザーが異なるアクセス方法を使用する必要がある場合、この機能は、ユーザーが任意の同等のURLを指定し、Gitが自動的に特定のユーザーにとって最適な代替URLに書き換えることを可能にします。 複数の insteadOf 文字列が特定のURLに一致する場合、最も長い一致が使用されます。

注意: プロトコルの制限は、書き換えられたURLに適用されることに注意してください。 リライトによってカスタムプロトコルまたはリモートヘルパーを使用するようにURLが変更された場合は、リクエストを許可するように protocol.*.allow 構成を調整する必要があります。 特に、サブモジュールに使用する予定のプロトコルは、デフォルトの user ではなく always に設定する必要があります。 上記 protocol.allow の説明を参照してください。

url.<base>.pushInsteadOf

この値で始まるURLはプッシュされません。代わりに、<base>で始まるように書き直され、結果のURLがにプッシュされます。 あるサイトが多数のリポジトリを提供し、それらを複数のアクセス方法で提供し、そのうちのいくつかはプッシュを許可しない場合、この機能は、サイト上で見たことのないリポジトリであっても、プル専用のURLを指定して、Gitが自動的に適切なURLを使ってプッシュすることを可能にします。 複数の pushInsteadOf 文字列が特定のURLに一致する場合、最も長い一致が使用されます。 リモートに明示的な pushurl がある場合、Gitはそのリモートのこの設定を無視します。

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) の「environment variables」セクションを参照してください。代わりに認証資格情報(authentication credentials)を探している場合は、 credential.username オプションを参照してください。

user.useConfigOnly

user.emailuser.name のデフォルトを推測しようとせず、代わりに構成からのみ値を取得するようにGitに指示します。 たとえば、複数のメールアドレスがあり、リポジトリごとに異なるアドレスを使用する場合、 グローバル設定でこの設定オプションを true に設定し、名前を指定すると、 Gitは、新しく複製されたリポジトリで新しくコミットを行う前に、電子メールを設定するように求めるプロンプトを表示します。 デフォルトは`false`です。

user.signingKey

git-tag(1) または git-commit(1) が、署名付きタグまたはコミットを作成するときに自動的に使用するキーを選択していない場合は、この変数を使用してデフォルトの選択をオーバーライドできます。 このオプションは変更されずにgpgの --local-user パラメータに渡されるため、gpgがサポートする任意のメソッドを使用してキーを指定できます。

versionsort.prereleaseSuffix (非推奨)

versionsort.suffix の非推奨のエイリアス。 versionsort.suffix が設定されている場合は無視されます。

versionsort.suffix

linkgit:git-tag [1]でバージョンの並べ替えが使用されている場合でも、基本バージョンが同じで接尾辞が異なるタグ名は辞書式順序で並べ替えられます。 例えば、メインリリースの後に表示されるプレリリースタグ(例: 1.0 の後の 1.0-rc1)。 この変数を指定して、異なる接尾辞を持つタグのソート順を決定できます。

この変数に単一の接尾辞(suffix)を指定すると、その接尾辞を含むタグ名は、対応するメインリリースの前に表示されます。 例えば、変数が -rc に設定されている場合、すべての 1.0-rcX タグは 1.0 の前に表示されます。 複数回指定した場合、1つのサフィックスにつき1回だけ、設定中のサフィックスの順番でタグ名の並べ替え順が決定されます。 例えば、構成で -pre`が `-rc の前に表示されている場合、すべての 1.0-preX タグが 1.0-rcX タグの前にリストされます。 さまざまな接尾辞を持つタグに対するメインリリースタグの配置順序は、他の接尾辞群の中で空の接尾辞を指定することで決定できます。 例えば、接尾辞 「-rc」と「」と「-ck」と「-bfs」がこの順序で構成に表示される場合、すべての v4.8-rcX`タグが最初にリストされ、次に `v4.8 がリストされ、その次が v4.8-ckX で、最後に v4.8-bfsX です。

複数の接尾辞(suffixes)が同じタグ名に一致する場合、そのタグ名は、タグ名の最初の位置から始まる接尾辞に従って並べ替えされます。 一致する複数の異なる接尾辞がその最も早い位置から始まる場合、そのタグ名はそれらの接尾辞の最長のものに従って並べ替えされます。 異なる接尾辞間の並べ替え順は、それらが複数の構成ファイルに渡る場合は未定義です。

web.browser

一部のコマンドで使用できるWebブラウザを指定します。 現在、 git-instaweb(1)git-help(1) のみが使用できます。

worktree.guessRemote

ブランチが指定されておらず、 -b や ` -B` や --detach のいずれも使用されていない場合、 git worktree add はデフォルトでHEADから新しいブランチを作成します。 worktree.guessRemote がtrueに設定されている場合、 worktree add は、名前が新しいブランチ名と一意に一致するリモート追跡ブランチを見つけようとします。 そのようなブランチが存在する場合、それはチェックアウトされ、新しいブランチの「アップストリーム」として設定されます。 そのような一致が見つからない場合は、フォールバックして現在のHEADから新しいブランチを作成します。

BUGS

非推奨の [section.subsection] 構文を使用する場合、サブセクションに少なくとも1つの大文字が指定されていると、値を変更すると、変更ではなく複数行のキーが追加されます。たとえば、設定が以下のようになっている場合

  [section.subsection]
    key = value1

git config section.Subsection.key value2 を実行すると、以下のようになります。

  [section.subsection]
    key = value1
    key = value2

GIT

Part of the git(1) suite