git-config(1) Manual Page

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

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

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

このキーワードに続くデータは、標準のグロブ・ワイルドカード(globbing wildcards)と、複数コンポーネントに一致する 2 つの追加ワイルドカード */ と /* を使用したパターンと見なされます。 このキーワードが最初に表れた時、構成ファイルの残りでremote URL がスキャンされます(値は適用されません)。 このパターンに一致するremote URL が少なくとも 1 つ存在する場合、インクルード条件が満たされます。

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

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

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

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

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

これらの変数は、 新しいユーザーを支援するために設計されたさまざまなオプションの、 ヘルプ・メッセージを制御します。 設定を行わないままにすると、 Git はメッセージを抑止する方法と共にヘルプ・メッセージを表示します。 対応する変数を false に設定することで、 あなたが問題を理解し、 当該ヘルプ・メッセージが必要なくなったことを Git に伝えることができます。

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

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

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

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

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

作業ツリーの .gitattributes ファイルの代わりに、 属性(attributes)を読み取るためのリポジトリ内のツリーへの参照。 値が有効なツリー・オブジェクトに解決されない場合は、 代わりに空のツリーが使用されます。 GIT_ATTR_SOURCE 環境変数または --attr-source コマンド・ライン・オプションが使用されている場合、 この構成変数は効果がありません。

参照名にマッチさせるために使用される正規表現。このパターンに一致するコミット(および下記の bitmapPseudoMerge.<name>.sampleRate や bitmapPseudoMerge.<name>.threshold などの基準を満たすコミット)は、 擬似マージ・ビットマップ(pseudo-merge bitmap)に含めることができるとみなされます。

連続する擬似マージ・ビットマップ・グループのサイズが減少する速度を決定します。 負ではない必要があります。 このパラメータは、関数 f(n) = C * n^-k の k と考えることができます。 ここで、 f(n) は n 番目のグループのサイズです。

不安定(unstable)な疑似マージ・ビットマップに含めるために選択される、(参照先端のうち)ビットマップ化されていないコミットの割合を決定します。 0 と 1 の間 (両端を含む) でなければなりません。デフォルトは 1 です。

不安定(unstable)な疑似マージ・ビットマップに含める候補となる、 ビットマップ化されていないコミット(上記の参照先端のうち)の最小経過期間を決定します。 デフォルトは 1.week.ago です。

コミットを分散させる擬似マージ・コミットの最大数を決定します。

安定(stable)した疑似マージ・ビットマップの候補であるコミットの最小経過期間を決定します(上記の参照先端の中で。 ただし、 安定した(stable)コミットは既にビットマップでカバーされている場合でも候補とみなされます)。 デフォルトは 1.month.ago です。

安定(stable)した疑似マージ・ビットマップ(psuedo-merge bitmap)のサイズ(コミット数)を指定します。 デフォルトは 512 です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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 には相対パス設定 . (ピリオド)が使用できます。

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

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

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

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

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

bundle.* キーは、 git clone --bundle-uri オプションで見つかったバンドル・リスト・ファイルに現れる場合があります。 これらのキーは現在、 リポジトリ構成ファイル(repository config file)に配置されても効果はありませんが、 将来的には変更される予定です。 詳細については、 the bundle URI design document を参照してください。

この整数値は、 バンドル・リストで使用されるバンドル・リスト形式のバージョンを通知します。 現在、受け入れられる値は 1 のみです。

この文字列値は、 all か any のどちらかである必要があります。 この値は、 バンドル情報を完全に理解してバンドル解除(unbundle)するにはアドバタイズされたすべてのバンドルが必要か(all)、 あるいはリストされたバンドル URI のいずれか 1 つで十分であるか(any)を示します。

この文字列値のキーが存在する場合、 バンドル・リストは 増分 git fetch コマンド(incremental git fetch commands)で適切に動作するように設計されています。 ヒューリスティック(heuristic)とは、 クライアントがダウンロードする必要があるバンドルのサブセットを決定するのに役立つ追加のキーがバンドルごとに利用可能であることを示します。 現在理解できる唯一の値は creationToken です。

bundle.<id>.* キーはバンドル・リスト内の単一の項目を記述するために使用され、 識別目的で <id> の下にグループ化されます。

この文字列値は、 Git がこの <id> のコンテンツにアクセスできる URI を定義します。 この URI はバンドル・ファイルまたは別のバンドル・リストである可能性があります。

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

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

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

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

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

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

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

部分(partial)クローン・フィルタが提供され(git-rev-list(1) の --filter を参照)、かつ、 --recurse-submodules が使用されている場合は、フィルタをサブモジュールにも適用します。

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

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

行の年齢に応じて、 git blame --color-by-age の行注釈の色を指定します。

前の行と同じコミットからのものである場合、指定の色を使用して git Blame --color-lines の行注釈を色付けします。 デフォルトはシアン(cyan)色です。

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

ブランチの色付けにスタマイズ色を使用します。 <slot> は、 current(現在のブランチ)、 local(ローカルブランチ)、 remote(refs/remotes/ 内のリモート追跡ブランチ)、 upstream(アップストリーム追跡ブランチ）、 plain(その他のref)、のいずれかです。

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

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

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

always に設定すると、常に一致を強調表示します。 false(または never)の場合、決して一致を強調表示しません。 true または auto に設定すると、出力が端末に書き込まれる場合にのみ色を使用します。 設定されていない場合は、 color.ui の値が使用されます(デフォルトでは auto)。

grepの色付けにカスタマイズ色を使用します。 <slot> は、指定の色を使用する行の部分を指定します。

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

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

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

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

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

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

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

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

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

ステータスの色付けにカスタマイズ色を使用します。 <slot> は次から一つを選択します。 header(ステータスメッセージのヘッダーテキスト)、 added または updated((追加されたがコミットされていないファイル)、 changed(変更されたがインデックスに追加されていないファイル)、 untracked(Git によって追跡されていないファイル)、 branch(現在のブランチ)、 nobranch(「no branch」警告を表示する色。デフォルトは赤)、 localBranch または remoteBranch(ブランチと追跡情報をステータス表示する際の、ローカルブランチとリモートブランチの名前) または unmerged (変更がマージされていないファイル)

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

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

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

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

git branch でブランチリストを列出力するかどうかを指定します。 詳細については、 column.ui を参照してください。

git clean -i でアイテムを一覧表示するときのレイアウトを指定します。これにより、常にファイルとディレクトリが列表示されます。 詳細については、 column.ui を参照してください。

git status で追跡されていないファイルを列表示するかどうかを指定します。 詳細については、 column.ui を参照してください。

git tag でタグリストを列出力するかどうかを指定します。 詳細については、 column.ui を参照してください。

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

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

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

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

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

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

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

廃止されました。 true ならば commitGraph.changedPathsVersion=-1 と、 そして、 false ならば commitGraph.changedPathsVersion=0 と同等です。 (commitGraph.changedPathVersion も設定されている場合は、 commitGraph.changedPathsVersion の方が優先されます。)

Git が読み書きする、 変更されたパスのブルーム・フィルター(the changed-path Bloom filters)のバージョンを指定します。 -1, 0, 1, 2 のいずれかになります。 注意: 1 を超える値は、 変更されたパスのブルーム・フィルター(the changed-path Bloom filters)のバージョンをまだ理解していない古いバージョンの Git と互換性が無い可能性があることに注意してください。 混合バージョン環境で操作する場合は注意してください。

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

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

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

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

このオプションは、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との下位互換性があります。

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

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

true に設定すると、この作業ディレクトリのための組み込みファイル・システム・モニター・デーモンが有効になります(git-fsmonitor--daemon(1))。

それ以外の場合、この変数には fsmonitorフック・コマンドの
パス名が含まれます。

「fsmonitor」フックを呼び出すときに使用するプロトコル・バージョンを設定します。

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

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

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

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

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

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

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

この変数を「true」に設定することは、すべてのファイルで「text」属性を「auto」に設定し、core.eolを「crlf」に設定することと同じです。 作業ディレクトリに CRLF 行末があり、リポジトリにLF行末がある場合は、trueに設定します。 この変数は「input」に設定できます。この場合、出力変換は実行されません。

working-tree-encoding 属性で使用された場合に Git が UTF-8 のラウンドトリップチェックを行うエンコーディングの、カンマや空白で区切られたリスト(gitattributes(5) を参照)。デフォルト値は SHIFT-JIS です。

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

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

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

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

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

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

alternateからの参照を一覧表示する場合は、指定のプレフィックスで始まる参照のみを一覧表示します。プレフィックスは git-for-each-ref(1) への引数として指定されたかのようにマッチングします。複数のプレフィックスを一覧表示するには、それらを空白で区切ります。 core.alternateRefsCommand が設定されている場合、 core.alternateRefsPrefixes を設定しても効果ありません。

trueの場合、このリポジトリは「ベア」(bare;ベアリポジトリ)であると見なされ、作業ディレクトリは関連付けられていません。この場合、 git-add(1) や git-merge(1) など、作業ディレクトリを必要とする多くのコマンドが無効になります。

作業ツリーのルートへのパスを設定します。 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 のいずれも指定されていない場合、現在の作業ディレクトリが作業ツリーの最上位と見なされます。

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

リポジトリの形式とレイアウトのバージョンを識別する内部変数。 gitrepository-layout(5) 参照。

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 です。

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

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

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

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

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

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

「大きい」(big)と見なされるファイルのサイズは、以下で説明するように、多数の git コマンドの動作と、そのようなファイルがリポジトリ内に格納される方法を変更します。 デフォルトは 512 MiB です。 k または m または g の一般的な単位サフィックスがサポートされています。

.gitignore (ディレクトリごと)と .git/info/exclude に加えて、追跡されることを意図されていないパスを記述するパターンを含むファイルへのパス名を指定します。 デフォルトは $XDG_CONFIG_HOME/git/ignore です。 $XDG_CONFIG_HOME が設定されていないか空の場合、代わりに $HOME/.config/git/ignore が使用されます。 gitignore(5) を参照してください。

パスワードを対話的に要求する一部のコマンド(svnやhttpインターフェイスなど)は、この変数の値を介して指定された外部プログラムを使用するように指示できます。 GIT_ASKPASS 環境変数でオーバーライドできます。設定されていない場合は、 SSH_ASKPASS 環境変数の値にフォールバックするか、それが失敗した場合は、単純なパスワードプロンプトにフォールバックします。外部プログラムには、コマンドライン引数として適切なプロンプトが与えられ、その標準出力にパスワードを書き出す事になっています。

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

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

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

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

[core]
# 古目のバージョン用の「1文字」
commentChar = "#"
# 新しいバージョン用の「文字列」(ファイル内で commentChar より
# 後で現れるため、 commentChar をオーバーライドします)
commentString = "//"

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

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

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

注意すべき一般的な空白(whitespace)の問題のコンマ(,)区切りのリスト。 gitdiff は color.diff.whitespace を使用してそれらを強調表示し、 git apply --whitespace = error はそれらをエラーと見なします。 接頭辞 - を付けて、それらのいずれかを無効にすることができます(例: -trailing-space):

作成または変更時に core.fsyncMethod を介して強化する必要があるリポジトリのコンポーネントのコンマ区切りリスト。 コンポーネントの前に - を付けることで、コンポーネントの堅牢化を無効にすることができます。 堅牢化されていないアイテムは、不正なシステム・シャットダウンが発生した場合に失われる可能性があります。 特別な要件がない限り、このオプションを空のままにするか、 committed または added または all のいずれかを選択することをお勧めします。

fsync および関連するプリミティブを使用してリポジトリ・データを堅牢化するために Git が使用する戦略を示す値。

このブール値は、オブジェクトファイルを書き込むときに fsync() を有効にします。 この設定は非推奨です。 代わりに core.fsync を使用してください。

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

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

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

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

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

trueの場合、gitはcommit-graphファイル(存在する場合)を読み取り、コミットのグラフ構造をパースします。デフォルトはtrueです。詳細については、 git-commit-graph(1) を参照してください。

false に設定すると、コマンドラインで --no-replace-objects オプションが指定されたかのように振る舞います。詳細については git(1) と git-replace(1) を参照してください。

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

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

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

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

Git がツリーのトラバース中に再帰的に使用できる最大の深さ(たとえば "a/b/cde/f" の深さは 4)。 これは、 Git を正常に中止で(abort cleanly)きるようにするためのフェイルセーフであり、 通常は調整する必要はありません。 Git が MSVC でコンパイルされる場合、 デフォルトは 512 です。 それ以外の場合、 デフォルトは 2048 です。

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

デフォルトでは、 Git および、 構成済の認証情報(credential)ヘルパーは、 新しい認証情報(credential)が必要な場合にユーザー入力を求めます。 これらのヘルパーの多くは、 保存された資格情報がまだ有効であれば、 それらに基づいて認証成功とします。 Git からのユーザー対話の可能性を回避するには、 credential.interactive=false を設定します。 一部の資格情報ヘルパーはこのオプションも考慮します。

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

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

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

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

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

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

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

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

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

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

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

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

このブール値が true に設定されている場合、 diff.external コマンドは、 diff(1） のように、 入力ファイル達が等しいとみなされる場合は終了コード 0 を返し、 異なるとみなされる場合は 1 を返すことが期待されます。 これがデフォルトである false に設定されている場合、 コマンドは入力ファイル達が等しいかどうかに関係なく終了コード 0 を返すことが期待されます。 これら以外終了コードがあると Git は致命的なエラー(fatal error)を報告します。

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

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

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

設定されている場合、 git diff はこのソース・プレフィックスを使用します。 デフォルトは a/ です。

設定されている場合、 git diff はこの宛先プレフィックスを使用します。 デフォルトは b/ です。

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

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

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

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

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

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

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

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

このブール値が true に設定されている場合、 diff.<driver>.command コマンドは、 diff(1) のように、 入力ファイル達が等しいとみなされる場合は終了コード 0 を返し、 異なるとみなされる場合は 1 を返すことが期待されます。 これがデフォルトである false に設定されている場合、 コマンドは入力ファイル達が等しいかどうかに関係なく終了コード 0 を返すことが期待されます。 これら以外の終了コードがあると、 Git は致命的なエラー(fatal error)を報告します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

呼び出された difftool がゼロ以外の終了ステータス(exit status)を返す場合は、difftool を終了(exit)します。

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

デフォルトで diff.guitool を使用するには true を設定します(引数 --gui を指定するのと同じです)。 DISPLAY 環境変数の値に応じて diff.guitool または diff.tool を選択するには auto を設定します。 なおデフォルトは false で、 diff.guitool を使用するには --gui 引数を明示的に指定する必要があります。

特に明記されていない限り、 core.repositoryFormatVersion が 1 で無い場合、 拡張機能(extension)を指定するとエラーになります。 gitrepository-layout(5) を参照してください。

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

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

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

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

このオプションは、 git fetch(および git pull の基になるフェッチ)が入力されたサブモジュールに再帰的にフェッチするかどうかを制御します。 このオプションは、ブール値または on-demand のいずれかに設定できます。 ブール値に設定すると、フェッチとプルの動作が変更され、trueに設定されている場合は無条件にサブモジュールに再帰し、falseに設定されている場合はまったく再帰しません。 on-demand に設定すると、フェッチとプルは、スーパープロジェクトがサブモジュールの参照を更新するコミットを取得したときにのみ、入力されたサブモジュールに再帰します。 デフォルトは on-demand 、または submodule.recurse が設定されている場合はその値です。

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

fsck.<msg-id> のように機能しますが、 git-fsck(1) の代わりに git-fetch-pack(1) によって使用されます。 詳細については、 fsck.<msg-id> のドキュメントを参照してください。

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

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

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

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

true の場合、 fetch は使用可能なすべてのリモートの更新を試みます。 この動作は、 --no-all を渡すか、 または、 取得先の 1 つ以上のリモートを明示的に指定することによってオーバーライドできます。 デフォルトは false です。

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

サーバーによって送信されるパックファイルの内容をネゴシエートするときに、ローカルリポジトリ内のコミットに関する情報がどのように送信されるかを制御します。 consecutive に設定すると、連続したコミットをそれぞれチェックするアルゴリズムを使用します。 skipping に設定すると、収束を高速化するためにコミットをスキップするアルゴリズムが使用されますが、必要以上の大きさのパックファイルが生成される可能性があります。 または、 noop に設定して情報をまったく送信しないようにします。これにより、ほぼ確実に必要以上に大きなパックファイルが生成されますが、ネゴシエーション・ステップはスキップされます。 default に設定すると、それ以前に行われた設定をオーバーライドしてデフォルトの振る舞いをします。 デフォルトは通常 consecutive ですが、 feature.experimental が true の場合、デフォルトは skipping です。 値が不明な場合、 git fetch でエラーが発生します。

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

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

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

この値には、 元の Git サーバーからの増分フェッチを実行する前に、 バンドル URI から Git オブジェクト・データをダウンロードするための URI が格納されます。これは、 git-clone(1) の --bundle-uri オプションの動作に似ています。 指定されたバンドル URI に増分フェッチ用に編成されたバンドル・リストが含まれている場合、git clone --bundle-uri では fetch.bundleURI 値を設定します。

fetch.bundleURI を使用して「creationToken」ヒューリスティックを使用するバンドル・リストから増分フェッチする場合、 この設定値には、 ダウンロードされたバンドルの、 最大 creationToken 値が格納されます。 この値は、 通知された creationToken がこの値を超えない限り、 その後のバンドルがダウンロードされないようにするために使用されます。

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

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

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

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

--[no-]force-in-body-from オプションのデフォルト値を format-patch に提供します。 デフォルトは false です。

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

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

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

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

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

format-patchのデフォルトは、Gitバージョン番号を含む署名を出力することです。 この変数を使用して、そのデフォルトを変更します。 この変数を空の文字列("")に設定すると、署名の生成を抑制します。

この変数で指定されたファイルの内容が署名として使用されることを除いて、 format.signature と同じように機能します。

format-patchのデフォルトは、接尾辞が .patch のファイルを出力することです。 この変数を使用して、その接尾辞を変更します(必要に応じて、必ずドット(.)を含めてください)。

電子メール送信用に、非ASCII文字を含む電子メールヘッダーを「Q-encoding」(RFC 2047で説明)でエンコードします。 デフォルトはtrueです。

log/show/whatchanged コマンドのpretty形式のデフォルト。 git-log(1) や git-show(1) や git-whatchanged(1) を参照してください。

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

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

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

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

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

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

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

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

"^>+From " 行をエスケープするために --stdout が使用されている場合に、 堅牢な "mboxrd" 形式を有効にするブール値。

設定すると、 パッチに送信元または宛先のプレフィックスが表示されなくなります。 これは、 git diff で使用される diff.noprefix オプションと同等です(ただし、 format-patch では無視されます)。 これを設定すると、 あなたが生成したパッチを受信した人は -p0 オプションを使用してパッチを適用する必要があることに注意してください。

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

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

デフォルトでは、 fsmonitor デーモンはネットワークにマウントされたリポジトリの操作を拒否します。 fsmonitor.allowRemote を true に設定すると、この振る舞いをオーバーライドします。 この設定は core.fsmonitor が true に設定されている場合にのみ尊重されます。

この Mac OS 固有のオプションが設定されている場合、 fsmonitor デーモンと、 様々な Git コマンド間の通信に使用される Unix ドメイン・ソケットを作成するディレクトリを指定します。 ディレクトリはネイティブな Mac OS ファイルシステム上に存在する必要があります。 core.fsmonitor が true に設定されている場合にのみ尊重されます。

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

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

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

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

システムがサポートしている場合、 git gc --auto は即座に戻り、 実行はバックグラウンドで行われます。 デフォルトは true です。 この構成変数は、 maintenance.autoDetach が設定されていない場合のフォールバックとして機能します。

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

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

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

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

到達不能なオブジェクトを緩いオブジェクトとしてではなく、クラフト・パック(cruft pack)(git-repack(1) 参照)に格納します。 デフォルトは true です。

再パックするときは、 新しいクラフト・パック(cruft packs)のサイズを制限してください。 この設定に加えて --max-cruft-size を指定した場合、 コマンド・ライン・オプションが優先されます。 git-repack(1) の --max-cruft-size オプションを参照してください。

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

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

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

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

オブジェクトを削除するかどうかを検討するとき(クラフト・パックを生成するとき、 または到達できないオブジェクトを緩いオブジェクトとして保存するとき)、 指定のコマンドを実行するためにシェルを使用します。 出力は、その古さに関係なく、 Git が "recent" と見なすオブジェクト ID として解釈されます。 mtime を "now" として扱うことにより、 出力に記載されているすべてのオブジェクト(およびその子孫)は、 実際の古さに関係なく保持されます。

再パックするときに、 この設定で指定したフィルターを使用して、 特定のオブジェクトを別のパック・ファイルに移動します。 git-repack(1) の --filter=<filter-spec> オプションを参照してください。

再パックで gc.repackFilter を参照するフィルターを使用する場合、 この設定で指定された場所は、 フィルタリングされたオブジェクトを含むパック・ファイルの作成に使用されます。 警告 指定された場所は、Git 代替メカニズム(Git alternates mechanism)などを使用してアクセスできる必要があり、 そうでない場合、 そのパック・ファイル内のオブジェクトにアクセスできない可能性があるため、 Git によってリポジトリが壊れていると見なされる可能性があります。 git-repack(1) の --filter-to=<dir> オプションと gitrepository-layout(5) の「objects/info/alternates」セクションを参照してください。

以前に解決した競合するマージの記録は、「git rerere gc」が実行されるときに、この設定値で指定の日数保持されます。より人間が読める「1.month.ago」などを使用することもできます。デフォルトは60日です。 git-rerere(1) を参照してください。

git rerere gc が実行されると、解決していない競合するマージの記録がこの設定値の日数保持されます。より人間が読める `1.month.ago`などを使用することもできます。デフォルトは15日です。 git-rerere(1) を参照してください。

この文字列を各コミットメッセージに追加します。この機能を無効にするには、空の文字列に設定します。 デフォルトは "via git-CVS emulator" (git-CVSエミュレーター経由)です。

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

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

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

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

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

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

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

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

説明については gitweb(1) を参照してください。

説明については gitweb.conf(5) を参照してください。

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

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

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

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

このコマンドは、 user.signingkey が設定されておらず、かつ、 ssh 署名が要求されたときに実行されます。 正常に終了すると、出力の最初の行に key:: で始まる有効な ssh 公開鍵あるものと期待します。 これにより、 user.signingKey を静的に構成することが実際的でない場合に、スクリプトが正しい公開鍵を動的に検索(lookup)できるようになります。 これはたとえば、キーまたは SSH 証明書が頻繁にローテーションされる場合や、適切なキーの選択が git にとって未知の外部要因に依存する場合などです。

信頼できる ssh 公開鍵を含むファイル。 このファイルは、1行以上のプリンシパル(principals)とそれに続く ssh 公開鍵で構成されます。 例: user1@example.com,user2@example.com ssh-rsa AAAAX1... 詳細については、 ssh-keygen(1) の「ALLOWED SIGNERS」を参照してください。 プリンシパル(principal)は、キーを識別するためにのみ使用され、署名を検証(verify)するときに使用できます。

SSH KRL または取り消された公開鍵のリスト(プリンシパル(principal)プレフィックスなし)。 詳細については、 ssh-keygen(1) を参照してください。 公開鍵がこのファイルで見つかった場合、その公開鍵は常に信頼レベル never として扱われ、署名は無効として表示されます。

trueに設定すると、デフォルトで -n オプションが有効になります。

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

デフォルトのマッチング動作を設定します。 basic または extended または fixed または perl の値を使用すると、それぞれに応じて --basic-regexp または ` --extended-regexp` または --fixed-strings または --perl-regexp オプションが有効になります。 値 default は grep.extendedRegexp オプションを使用して basic と extended のどちらかを選択します。

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

使用する grep ワーカー・スレッドの数。 設定しない場合(または 0 に設定した場合)、 Git は使用可能な論理コアの数と同じ数のスレッドを使用します。

trueに設定すると、デフォルトで --full-name オプションが有効になります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最初に未認証の試行を行って 401 応答を受信することなく、 認証を試行します。 これを使用して、 すべてのリクエストが認証されていることを確認できます。 http.emptyAuth が true に設定されている場合、 この値は効果がありません。

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

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

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

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

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

HTTP リクエストの送信時に libcurl が最初に使用するホスト名解決情報。 この情報は、以下のいずれかの形式である必要があります:

デフォルトを強制する場合に、SSL接続をネゴシエートするときに使用するSSLバージョン。 使用可能なデフォルトバージョンは、libcurlがNSSまたはOpenSSLのどちらに対して構築されたか、および使用中の暗号ライブラリの特定の構成によって異なります。 内部的には、これにより CURLOPT_SSL_VERSION オプションが設定されます。 このオプションの形式とサポートされているSSLバージョンの詳細については、libcurlのドキュメントを参照してください。 現在、このオプションの可能な値は以下のとおりです:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HTTP転送速度(バイト/秒)が http.lowSpeedLimit 未満の状態が http.lowSpeedTime 秒を超えると、 転送は中断(abort)されます。 GIT_HTTP_LOW_SPEED_LIMIT および GIT_HTTP_LOW_SPEED_TIME 環境変数でオーバーライドできます。

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

HTTP サーバーに提示される HTTP USER_AGENT 文字列。 デフォルト値は、git/1.7.1などの Git クライアントのバージョンを表します。 このオプションを使用すると、この値を Mozilla/4.0 などのより一般的な値にオーバーライドできます。 これは、たとえば、 HTTP 接続を一連の一般的な USER_AGENT 文字列(ただし、 git/1.7.1 などは含まない、)に制限するファイアウォールを介して接続する場合に必要になることがあります。 GIT_HTTP_USER_AGENT 環境変数でオーバーライドできます。

gitがHTTPリダイレクトに従うべきかどうか。 true に設定されている場合、gitは、検出したサーバーによって発行されたリダイレクトを透過的に追跡します。 false に設定すると、gitはすべてのリダイレクトをエラーとして扱います。 initial に設定されている場合、gitはリモートへの最初のリクエストに対してのみリダイレクトに従いますが、後続のフォローアップHTTPリクエストに対しては追跡しません。 gitはリダイレクトされたURLをフォローアップリクエストのベースとして使用するため、通常はこれで十分です。 デフォルトは initial です。

上記の http.* オプションはいずれも、一部のURLに選択的に適用できます。 構成キーがURLと一致するように、構成キーの各要素がURLの要素と以下の順序で比較されます:

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

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

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

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

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

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

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

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

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

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

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

他の構成ファイルをインクルードするための特別な変数。 git-config(1) ドキュメントの「CONFIGURATION FILE」セクション、特に「Includes」および「Conditional includes」サブセクションを参照してください。

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

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

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

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

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

有効にすると、 インデックス・ファイルの末尾ハッシュを計算しません。 これにより、 git add または git commit または git status などのインデックスを操作する Git コマンドが高速化されます。 チェックサムを保存する代わりに、 値 0 の末尾のバイト・セットを書き込み、 計算がスキップされたことを示します。

テンプレートのコピー元のディレクトリを指定します。 (See the "TEMPLATE DIRECTORY" section of git-init(1).)

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

新しいリポジトリのデフォルトのオブジェクト形式をオーバーライドできるようにします。 git-init(1) の --object-format= を参照してください。 コマンド・ライン・オプションと GIT_DEFAULT_HASH 環境変数の両方とも、 この設定より優先されます。

新しいリポジトリのデフォルトの ref ストレージ形式をオーバーライドできるようにします。 git-init(1) の --ref-format= を参照してください。 コマンド・ライン・オプションと GIT_DEFAULT_REF_FORMAT 環境変数の両方とも、 この設定より優先されます。

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

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

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

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

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

true に設定すると、 ユーザーが対話型コマンドで 1 つのキーで 1 文字の入力を提供できるようになります(つまり、Enterキーを押さずに)。 これは現在、 git-add(1) と git-checkout(1) と git-restore(1) と git-commit(1) と git-reset(1) と git-stash(1) の、 --patch モードで使用されています。

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

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

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

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

デフォルトでは、 git log は特定の既知の ref 名前空間の装飾(decorations)のみを表示します。 all が指定されている場合は、すべてのrefを装飾として表示します。

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

--diff-merges=on が指定されたときに使用される diff 形式を設定します。 詳細については、git-log(1) の --diff-merges を参照してください。 デフォルトは separate です。

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

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

trueの場合、最初のコミットは大きな作成イベントとして表示されます。 これは、空のツリーに対するdiffに相当します。 git-log(1) や git-whatchanged(1) などのツールは、通常はルートコミットを隠していますが、今後は表示されるようになります。 デフォルトでは True です。

trueの場合、 git-log(1) と git-show(1) と git-whatchanged(1) に --show-signature を想定させます。

trueの場合、 git-log(1) と git-show(1) と git-whatchanged(1) で --use-mailmap を想定させ、それ以外の場合は --no-use-mailmap を想定させます。 デフォルトではtrueです。

advertise (デフォルト)または allow または ignore の場合があります。 advertise`の場合、サーバーは `unborn (gitprotocol-v2(5) 説明があります)を送信するクライアントに応答し、プロトコルv2機能の広告(advertise)中にこの機能のサポートを広告します。 allow は advertise`と同一ですが、サーバーがこの機能のサポートを広告しない点が異なります。 これは、管理者が `allow を構成し、遅れて advertise を構成できるため、(たとえば、)アトミックに更新できない負荷分散サーバーに役立ちます。

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

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

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

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

多くの Git コマンドは、 データをリポジトリに書き込んだ後に自動メンテナンスをトリガーします。 このブール型構成オプションは、 この自動メンテナンスをフォアグラウンドで実行するか、 またはメンテナンス・プロセスを切り離し(detach)してバックグラウンドで実行し続けるかを制御します。

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

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

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

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

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

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

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

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

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

マージ時に競合するハンクが作業ツリーファイルに書き出されるスタイルを指定します。 デフォルトは merge`です。 これは、 `<<<<<<< 競合マーカー、 一方の側で行われた変更、 ======= マーカー、 もう一方の側で行われた変更、 >>>>>>> マーカー、 というスタイルです。 別のスタイル「diff3」は、 ||||||| マーカーと元のテキストを ======= マーカーの前に追加します。 merge スタイルは、 元のテキストの除外と、 行のサブセットが両側で一致する場合に競合領域から引き抜かれるという、 両方の理由により、 diff3 よりも競合領域が小さくなる傾向があります。 もう 1 つの代替スタイル zdiff3 は diff3 に似ていますが、 両側で一致する行が競合領域の開始または最後近くに現れる場合、競合領域から削除します。

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

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

trueの場合、これは --verify-signatures コマンドラインオプションと同等です。 詳細については、 git-merge(1) を参照してください。

ブランチ名に加えて、それらに関連付けられたブランチの説明テキストをログメッセージに入力します。デフォルトはfalseです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

vimdiff のバリエーション(<variant>)である、 vimdiff` や nvimdiff や gvimdiff のいずれかの分割ウィンドウ・レイアウトを構成します。 --tool=<variant> を指定して(または、merge.tool が <variant> として設定されている場合は --tool 無しで、) git mergetool を起動すると、 Git は mergetool.<variant>.layout を参照してツールのレイアウトを決定します。 バリエーション固有の設定が利用できない場合は、 vimdiff がフォールバックとして使用されます。 それも利用できない場合は、 4 つのウィンドウを含むデフォルトのレイアウトが使用されます。 レイアウトを設定するには、 git-mergetool(1) の 「BACKEND SPECIFIC HINTS」を参照してください。

マージ処理中、 Git は可能な限り多くの競合を自動的に解決し、 解決できない競合の周りに競合マーカーを含ませた MERGED ファイルを書き込みます。 LOCAL と REMOTE は通常、 Git の競合解決前のファイルのバージョンを表します。 この設定により LOCAL と REMOTE が上書きされ、 未解決の競合のみがマージ・ツールに表示されます。 mergetool.<tool>.hideResolved 構成変数を介してツールごとに構成できます。 デフォルトは false です。

マージを実行した後、競合マーカーを含む元のファイルを、拡張子 .orig のファイルとして保存できます。 この変数が false に設定されている場合、このファイルは保存されません。 デフォルトは true です(つまり、バックアップファイルを保持します)。

カスタム・マージ・ツールを呼び出すとき、 Gitは一時ファイルの組をツールに渡します。 ツールがエラーを返し、 この変数が true に設定されている場合、 これらの一時ファイルは保持されます。 それ以外の場合、 これらの一時ファイルはツールの終了後に削除されます。 デフォルトは false です。

Gitは、デフォルトで、競合するファイルの一時的な 「BASE」バージョンと「LOCAL」バージョンと「REMOTE」バージョンをワークツリーに書き込みます。 true に設定すると、Gitはこれらのファイルに一時ディレクトリを使用しようとします。 デフォルトは false です。

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

true を設定するとデフォルトで merge.guitool を使用します(引数 --gui を指定するのと同じです)。 または、 auto を設定すると DISPLAY 環境変数値に応じて merge.guitool または merge.tool を選択します。 デフォルトは false で merge.guitool を使用するには --gui 引数を明示的に指定する必要があります。

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

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

git log 系のコマンドでコミット・メッセージを表示する際に、 core.notesRef や GIT_NOTES_REF で設定したデフォルトに加えて、どのref (グロブ、または複数回指定されている場合は複数ref)からノートを読み込むかを指定します。

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

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

書き換え中にノートをコピーする場合は、ノートをコピーする(完全修飾された)refを指定します。 グロブと見なしたら、マッチするすべてのrefのノートがコピーされます。 この構成を複数回指定することもできます。

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

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

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

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

true または single かつ、 到達可能性ビットマップ(reachability bitmaps)が有効になっている場合、 パック・オブジェクトはビット・マップ化されたパックファイル部品をそのままで送信しようと試みます。 multi かつ、 マルチ・パックな到達可能性ビットマップが有効になっている場合、 パック・オブジェクトは MIDX 内の全てのパック部品を送信しようと試みます。

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

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

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

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

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

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

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

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

true の場合、 Git は実験的なアルゴリズムを使用して、 ビットマップを使用した到達可能性クエリを計算します。 すべての到達不可先端の完全なビットマップを構築してからそれらを OR 演算する代わりに、 到達不可先端を既存のビットマップへの追加分として処理し(つまり、 到達不可先端が存在する場合はそれらを結果に OR 演算し、 存在しない場合は無視します)、境界にビットマップを構築します。

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

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

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

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

true の場合、Git はビットマップ・インデックスに lookup table (検出表)セクションを含めます (記述されている場合)。 この表(table)は、個々のビットマップの読み込みをできるだけ遅らせるために使用されます。 これは、比較的大きなビットマップ・インデックスを持つリポジトリで役立ちます。 デフォルトは false です。

true の場合、git は利用可能なすべての .rev ファイルを読み取ります(gitformat-pack(5) 参照)。 false の場合、逆インデックスがイチから生成(generated from scratch)され、メモリに保存されます。 デフォルトは true です。

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

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

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

true に設定すると、 部分クローン(partial clone)の追加オブジェクトを取得(fetch)するときに --quiet とみなします。

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

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

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

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

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

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

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

true に設定すると、現在のブランチの上流追跡(upstream tracking)が存在しない場合、デフォルトのpushで --set-upstream を想定します。 このオプションは、 push.default オプションの simple や upstream や current で有効になります。 (push.default=current の振る舞いのように、)デフォルトで新しいブランチをデフォルトのremoteにプッシュしたい場合に便利で、これは、あなたが上流追跡(upstream tracking)も設定したい場合にも便利です。 このオプションの恩恵を受ける可能性が最も高いワークフローは、すべてのブランチがremoteで同じ名前を持つことが期待される「単純な」中央ワークフローです。

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

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

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

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

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

値は check または on-demand または only または no のいずれかで、 push --recurse-submodules と同じ動作になります。 設定されていない場合、 submodule.recurse が設定されていない限り、 デフォルトで no が使用されます(submodule.recurse が設定されている場合、 submodule.recurse の true 値は on-demand を意味します)。

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

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

false に設定すると、 pack.useBitmaps が true であっても git push のビットマップの使用が無効になり、他の git 操作でのビットマップの使用が妨げられません。 デフォルトは true です。

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

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

true に設定すると、 デフォルトで git-rebase(1) の --autosquash オプションが対話モードで有効になります。 これは --no-autosquash オプションでオーバーライドできます。

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

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

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

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

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

失敗した exec コマンドを自動的に再スケジュールします。 これは、対話モード (または --exec オプションが指定されている場合)でのみ意味があります。これは --reschedule-failed-exec オプションを指定するのと同じです。

falseに設定されている場合、デフォルトで --no-fork-point オプションを設定します。

デフォルトで --rebase-merges オプションを設定するかどうか、および設定方法。 rebase-cousins または no-rebase-cousins またはブール値を指定できます。 true または no-rebase-cousins に設定すると --rebase-merges=no-rebase-cousins と同等になり、 rebase-cousins に設定すると --rebase-merges=rebase-cousins と同等になります。 false に設定すると --no-rebase-merges と同等になります。 コマンドラインで --rebase-merges を渡すと引数の有無にかかわらず、 すべての rebase.rebaseMerges 設定がオーバーライドされます。

コミット件名(commit subjects)からラベル名を生成する場合、 名前をこの長さに切り詰めます。 デフォルトでは、 名前は NAME_MAX より少し小さくなるように切り詰められます(たとえば、 対応する緩い refs (loose refs)に対して .lock ファイルを書き込むことができるようにするためです)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ブロックを書き込むときに reftable バックエンドによって使用されるバイト単位のサイズ。 ブロック・サイズは書込器(writer)によって決定され、 2 の累乗である必要はありません。 参照は複数のブロックにまたがることはできないため、 ブロック・サイズはリポジトリで使用される最長の参照名またはログ・エントリより大きくなければなりません。

再開ポイントを作成する間隔。 ファイル作成時の再開ポイントは reftable バックエンドが決めます。 小さいブロック・サイズ(4k または 8k)には 16 ごと、 大きいブロック・サイズ(64k)には 64 ごとが好ましいです。

reftable バックエンドがオブジェクト・ブロックを書き込むかどうか。 オブジェクト・ブロックは、 オブジェクト ID を、 それらを指す参照に逆マッピングしたものです。

reftable バックエンドが新しいテーブルをスタックに追加するたびに、 自動圧縮を実行してテーブルが少量になるようにします。 バックエンドは、 テーブルが各テーブルのそれぞれのサイズに関して等比数列(geometric sequence)を形成することを保証することによってこれを行います。

reftable バックエンドが新しいテーブルをスタックに追加するときは常に、 中央の tables.list ファイルを更新する前にロックする必要があります。 この構成は、 別のプロセスがすでにロックを取得している場合に、 プロセスがロックを取得するまで待機する時間を制御します。 値 0 は、 まったく再試行しないことを意味します。 -1 は無期限に試行することを意味します。 デフォルトは 100(つまり、100 ミリ秒再試行)です。

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

リモート・リポジトリの URL 。 git-fetch(1) または git-push(1) を参照してください。 設定されたリモートには複数の URL を含めることができます。 この場合、 最初のものはフェッチに使用され、 その他すべてはプッシュに使用されます(remote.<name>.pushurl が定義されていないと仮定して)。 このキーを空の文字列に設定すると、 URL のリストがクリアされ、 以前の設定をオーバーライドできるようになります。

リモート・リポジトリのプッシュ URL 。 git-push(1) を参照してください。 設定されたリモートに pushurl オプションが存在する場合、 それは remote.<name>.url の代わりにプッシュに使用されます。 設定されたリモートには複数のプッシュ URL を含めることができます。 この場合、 プッシュはそれらすべてに送信されます。 このキーを空の文字列に設定すると、 URL のリストがクリアされ、 以前の設定をオーバーライドできるようになります。

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

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

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

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

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

非推奨の同義語: remote.<name>.skipFetchAll の非推奨の同義語(構成ファイル内で両方が異なる値で設定されている場合は、 最後に出現した値が使用されます)。

true の場合、このリモートは、 git-remote(1) の update サブコマンドの git-fetch(1) を使用して更新する時はスキップされ、 git maintenance のプリ・フェッチ・タスクでは無視されます。

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

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

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

これを値 <vcs> と設定すると、Gitは git-remote-<vcs> ヘルパーを使用してリモートと対話します。

trueに設定した時は、デフォルトでこのリモートからフェッチすると、(コマンドラインで --prune オプションが指定されているかのように、)リモートに存在しなくなったリモート追跡参照も削除されます。 fetch.prune 設定が存在する場合、それをオーバーライドします。

trueに設定した時、デフォルトでこのリモートからフェッチすると、一般に刈り込み(pruning)が remote.<name>.prune または fetch.prune または --prune を介して、アクティブ化されている場合、リモートに存在しなくなったローカルタグも削除されます。 fetch.pruneTags 設定存在する場合それをオーバーライドします。

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

このプロミサー・リモートからフェッチするときに適用されるフィルター。 この値を変更またはクリアした場合、その後のコミットのフェッチにのみ影響します。 ローカル・オブジェクト・データベースに既に存在するコミットの関連オブジェクトをフェッチするには、 git-fetch(1) の --refetch オプションを使用します。

このリモートから取得するときに使用されるサーバー・オプションのデフォルトのセット。 これらのサーバー・オプションは、 --server-option= コマンド・ライン引数によってオーバーライドできます。

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

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

trueに設定すると、 git repack が --pack-kept-objects が渡されたかのように動作します。 詳細については、 git-repack(1) を参照してください。 デフォルトは通常 false ですが、ビットマップインデックスが(--write-bitmap-index または repack.writeBitmaps のいずれかを介して)書き込まれている場合は true です。

trueに設定すると、 git repack が --delta-islands が渡されたかのように動作します。 デフォルトは false です。

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

false に設定すると、git-repack(1) は git-update-server-info(1) を実行しません。 デフォルトは true です。 git-repack(1) の -n オプションで true の場合、オーバーライドできます。

クラフト・パック(cruft pack)を生成するときに git-pack-objects(1) が使用するパラメータで、これらのパラメータはコマンドラインから与えることはできません。デフォルトと意味については、 pack.* 設定変数の対応する名前のを参照してください。

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

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

この変数を true に設定すると、 git revert は --reference オプションが指定されているかのように振る舞います。

Git が動作するベア(bare)・リポジトリを指定します。 現在サポートされている値は以下のとおりです:

これらの構成(config)エントリは、現在のユーザー以外の誰かが所有していても安全と見なされる Git 追跡ディレクトリを指定します。 デフォルトでは、Git は他の誰かが所有するリポジトリの Git 構成(config)をパースすることさえ拒否し、 そのフックを実行に関しては言うまでもありません。 この構成設定により、 ユーザーは例外を指定できます。 例えば、意図的に共有するリポジトリ用です (git-init(1) の --shared オプションを参照)。

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

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

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

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

true (デフォルト) の場合、編集する必要があるファイルを編集するために単一のエディター・インスタンスが生成されます(--annotate が使用されている場合はパッチ、 --compose が使用されている場合は要約)。 false の場合、ファイルは次々に編集され、そのたびに新しいエディター・インスタンスが生成されます。

送信前に確認するかどうかのデフォルトを設定します。 always または never または cc または compose または auto のいずれかでなければなりません。 これらの値の意味については、 git-send-email(1) ドキュメントの --confirm を参照してください。

true の場合 git-send-email(1) は --mailmap を想定し、 それ以外の場合は --no-mailmap を想定します。 デフォルトでは False です。

git-send-email(1) 固有の拡張メールマップ(mailmap)・ファイルの場所。 デフォルトのメールマップと mailmap.file が最初にロードされます。 したがって、 このファイル内のエントリは、 デフォルトのメールマップの場所(locations)内のエントリよりも優先されます。 gitmailmap(5) を参照してください。

sendemail.mailmap.file と似ていますが、 値はリポジトリ内の BLOB への参照として考慮されます。 sendemail.mailmap.file 内のエントリは、 このエントリより優先されます。 gitmailmap(5) を参照してください。

長い電子メール・アドレスのタイピングを回避するには、1 つまたは複数の電子メール・エイリアス・ファイルを指定します。 sendemail.aliasFileType も指定する必要があります。

sendemail.aliasesFile で指定されたファイルの形式。 mutt, mailrc, pine, elm, gnus, sendmail のいずれかでなければなりません。

これらの構成変数はすべて、git-send-email(1) コマンドライン・オプションのデフォルトを提供します。 詳細については、そのドキュメントを参照してください。

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

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

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

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

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

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

通常、スパース・チェックアウトでは、どのスパース・パターンとも一致しないファイルは、インデックスの SKIP_WORKTREE ビットでマークされ、作業ツリーから欠落します。 したがって、Git は通常、期待に反して SKIP_WORKTREE ビットを持つファイルが実際に作業ツリーに存在するかどうかを確認します。 Git がいずれかを見つけた場合、関連する SKIP_WORKTREE ビットをクリアすることにより、それらのパスが存在するものとしてマークします。 このオプションを使用して、そのような存在にもかかわらずスキップされたファイルが予期できることを Git に伝え、それらのチェックを停止することができます。

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

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

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

これがtrueに設定されている場合、 git stash show コマンドはstashエントリの追跡されていないファイル(untracked files)を表示します。 デフォルトはfalseです。 git-stash(1) の showコマンドの説明を参照してください。

これがtrueに設定されている場合、オプションのない git stash show コマンドは、パッチ形式でstashエントリを表示します。 デフォルトはfalseです。 git-stash(1)の showコマンドの説明を参照してください。

これがtrueに設定されている場合、オプションのない git stash show コマンドは、stashエントリのdiffstatを表示します。 デフォルトはtrueです。 git-stash(1) の showコマンドの説明を参照してください。

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

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

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

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

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

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

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

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

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

デフォルトはfalseです。 これがゼロ以外の数値、またはtrue(-1または無制限と同じ)に設定されている場合、サブモジュールの要約が有効になり、変更されたサブモジュールのコミットの要約が表示されます(git-submodule(1) の --summary-limit オプションを参照してください)。 diff.ignoreSubmodules が all に設定されている場合、または submodule.<name>.ignore=all であるサブモジュールに対してのみ、要約出力コマンドが抑制されることに注意してください。 そのルールの唯一の例外は、statusとcommitが、ステージされたサブモジュールの変更を表示することです。 無視されたサブモジュールの概要も表示するには、 --ignore-submodules=dirty コマンドラインオプションまたは git submodule summary コマンドを使用できます。これは同様の出力を表示しますが、これらの設定を尊重しません。

サブモジュールのURL。 この変数は、 git submodule init を介して .gitmodules ファイルから git config にコピーされます。 ユーザーは、 git submodule update を介してサブモジュールを取得する前に、構成されたURLを変更できます。 submodule.<name>.active も submodule.active も設定されていない場合、この変数の存在は、サブモジュールがgitコマンドに関係するかどうかを示すためのフォールバックとして使用されます。 詳細については、 git-submodule(1)および gitmodules(5) を参照してください。

影響を受ける唯一のコマンドである git submodule update によってサブモジュールが更新される方法。 git checkout --recurse-submodules などの他のコマンドは影響を受けません。 git submodule がサブモジュールと対話する唯一のコマンドであった場合、これは歴史的な理由で存在します。 submodule.active`や `pull.rebase などの設定はより具体的です。 これは、gitmodules(5) ファイルから git submodule init によって入力されます。 git-submodule(1) のupdateコマンドの説明を参照してください。

git submodule update --remote によって使用されるサブモジュールのリモートブランチ名。 このオプションを設定すると、 .gitmodules ファイルにある値が上書きされます。 詳細については、 git-submodule(1) および gitmodules(5) を参照してください。

このオプションは、このサブモジュールの再帰的フェッチを制御するために使用できます。 --[no-]recurse-submodules コマンドラインオプションを使用して git fetch と git pull をオーバーライドすることでオーバーライドできます。 この設定は、 gitmodules(5) ファイルの設定を上書きします。

どのような状況で git status とdiffファミリーがサブモジュールを変更済みとして表示するかを定義します。 all に設定すると、変更されたとは見なされません(ただし、ステータスの出力に表示され、ステージングされるとコミットされます)。 dirty は、サブモジュールのワークツリーへの全ての変更を無視し、 サブモジュールの HEAD と、 スーパープロジェクトに記録されたコミットの差異のみを考慮します。 untracked はさらに、 ワークツリー内の変更された追跡ファイルを持つサブモジュールを表示させます。 none (設定されていない場合のデフォルト)を使用すると、ワークツリーに追跡されていないファイルが変更されたサブモジュールも表示されます。 この設定は、このサブモジュールの .gitmodules で行われた設定を上書きします。両方の設定は、 --ignore-submodules オプションを使用してコマンドラインで上書きできます。 git submodule コマンドは、この設定の影響を受けません。

サブモジュールがgitコマンドに関係するかどうかを示すブール値。 この構成オプションは、 submodule.active 構成オプションよりも優先されます。 詳細については、 gitsubmodules(7) を参照してください。

サブモジュールが git コマンドの対象かどうかを判断するためにサブモジュールのパスと照合するために使用される pathspec を含む繰り返しフィールド。詳細は gitsubmodules(7) を参照してください。

コマンドがデフォルトで --recurse-submodules オプションを有効にするかどうかを示すブール値。 デフォルトは false です。

[実験的] --recurse-submodules または submodule.recurse=true を使用するときにブランチ支援(branching support)を有効にするブール値。 これを有効にすると、特定のコマンドが --recurse-submodules を受け入れるようになり、 すでに --recurse-submodules を受け入れている特定のコマンドがブランチを考慮するようになります。 デフォルトは false です。

同時に フェッチ/クローン されるサブモジュールの数を指定します。 正の整数を使用すると、その数までのサブモジュールを並列にフェッチできます。 値0は、適切なデフォルトを提供します。 設定されていない場合、デフォルトで1になります。

サブモジュールがcloneされるときに、サブモジュールがalternateを取得する方法を指定します。 可能な値は no 、superproject です。 デフォルトでは、参照を追加しない no が想定されています。 値が superproject に設定されている場合、cloneされるサブモジュールは、スーパープロジェクトのalternates locationを基準にしてalternates locationを計算します。

submodule.alternateLocation を介して計算されたサブモジュールのalternateでエラーを処理する方法を指定します。 可能な値は ignore 、 info 、 die です。デフォルトは die です。 ignore または info に設定されていて、計算されたalternateにエラーがある場合、alternateが指定されていないかのようにクローンが進行することに注意してください。

作成された注釈付きタグをGPG署名するかどうかを指定するブール値。 コマンドラインで --annotate が指定されている場合、このオプションよりも優先されます。

この変数は、 git-tag(1) によって表示されるときのタグの並べ替え順序を制御します。 --sort=<value> オプションが指定されていない場合、この変数の値がデフォルトとして使用されます。

すべてのタグをGPG署名するかどうかを指定するブール値。 自動スクリプトで実行しているときにこのオプションを使用すると、多数のタグが署名される可能性があります。 したがって、あなたは、エージェントを使用して、gpgパスフレーズを毎回入力しないようにするのが便利です。 このオプションは、 -u<keyid> または --local-user=<keyid> オプションによって有効にされるタグ署名の動作には影響しないことに注意してください。

この変数は、tarアーカイブエントリの許可ビットを制限するために使用できます。デフォルトは0002で、ワールド書き込みビット(world write bit)をオフにします。 特別な値 "user" は、アーカイブユーザーのumaskが代わりに使用されることを示します。 umask(2) および git-archive(1) を参照してください。

この変数は、通常のターゲット(normal target)宛先を制御します。 GIT_TRACE2 環境変数によってオーバーライドされる可能性があります。

この変数は、パフォーマンスターゲットの宛先を制御します。 GIT_TRACE2_PERF 環境変数によってオーバーライドされる可能性があります。

この変数は、イベントターゲットの宛先を制御します。 GIT_TRACE2_EVENT 環境変数によってオーバーライドされる可能性があります。

ブール値。 trueの場合、 time と filename と line フィールドは通常の出力(normal output)から省略されます。 GIT_TRACE2_BRIEF 環境変数によってオーバーライドされる可能性があります。 デフォルトはfalseです。

ブール値。 trueの場合、 time と filename と line フィールドはPERF出力から省略されます。 GIT_TRACE2_PERF_BRIEF 環境変数によってオーバーライドされる可能性があります。 デフォルトはfalseです。

ブール値。 trueの場合、 time と filename と line フィールドはイベント出力から省略されます。 GIT_TRACE2_EVENT_BRIEF 環境変数によってオーバーライドされる可能性があります。 デフォルトはfalseです。

整数。 イベント出力でネストされた領域(region)の必要な深さを指定します。この値より深い領域は省略されます。 GIT_TRACE2_EVENT_NESTING 環境変数によってオーバーライドされる可能性があります。 デフォルトは2です。

trace2出力に記録する必要がある「重要な」構成設定のパターンのコンマ区切りリスト。 たとえば、 core.*,remote.*.url を指定すると、trace2の出力には、構成された各リモートを一覧表示するイベントが含まれます。 GIT_TRACE2_CONFIG_PARAMS 環境変数によってオーバーライドされる可能性があります。 デフォルトでは設定されていません。

trace2出力に記録する必要がある「重要な」環境変数のコンマ区切りリスト。 たとえば、 GIT_HTTP_USER_AGENT,GIT_CONFIG を指定すると、trace2出力に、(いずれも設定されていると仮定して、)HTTPユーザーエージェントのオーバーライドとGit構成ファイルの場所をリストするイベントが含まれます。 GIT_TRACE2_ENV_VARS 環境変数によってオーバーライドされる可能性があります。 デフォルトでは設定されていません。

ブール値。 trueの場合、トレースターゲットの宛先を書き込み用に開くことができない場合、Gitはエラーメッセージを出力します。 デフォルトでは、これらのエラーは抑制され、トレースは黙って無効になっています。 GIT_TRACE2_DST_DEBUG 環境変数によってオーバーライドされる可能性があります。

整数。 トレース・ファイルをターゲット・ディレクトリに書き込むとき、 ファイル数がこの数を超える場合は、 追加のトレースを書き込まないでください。 代わりに、このディレクトリへのそれ以上のトレースをブロックする番兵ファイル(sentinel file)を作成します。 デフォルトは 0 で、 このチェックを無効にします。

構成された URL には、 <protocol>://<user>:<password>@<domain>/<path> の形式で平文(plaintext)の資格情報(credentials)を含めることができます。 (git-credential(1) の使用を優先して、)そのような構成の使用を警告または禁止することができます。 これは、 git-clone(1) や git-fetch(1) やgit-push(1) や その他の構成された URL の直接使用で使用されます。

fetch.fsckObjects または receive.fsckObjects が設定されていない場合、代わりにこの変数の値が使用されます。デフォルトはfalseです。

文字列 receive-pack と upload-pack は、最初の広告から除外するrefを決定するために使用します。 複数のプレフィックス文字列を指定するには、複数の定義を使用します。 この変数の値にリストされている階層の下にあるrefは除外され、 git push または git fetch に応答するときに非表示になります。 この構成のプログラム固有のバージョンについては、 receive.hideRefs および uploadpack.hideRefs を参照してください。

fetch.unpackLimit または receive.unpackLimit が設定されていない場合、代わりにこの変数の値が使用されます。 デフォルト値は100です。

ブール値。 trueの場合、クライアントプロセスとサーバープロセスは、一意のセッションIDをリモートの対応するプロセスに広告します。 デフォルトはfalseです。

true の場合、ローカルの git clone コマンドは、 Git プロトコルを介してクローン作業を続行する前に、 (広告(advertise)されている場合)リモート・サーバーにバンドル情報を要求し、 バンドルをダウンロードします。 デフォルトは false です。

true の場合、 object-info 機能がサーバーから広告されます。 デフォルトは false です。

trueの場合、クライアントが git archive --remote を使用して、ref先端から到達可能かどうかに関係なく、任意のツリーを要求できるようにします。詳細については、 git-upload-archive(1)の「SECURITY」セクションの説明を参照してください。デフォルトは false です。

この変数は transfer.hideRefs と同じですが、 upload-pack にのみ適用されます(したがって、プッシュではなくフェッチにのみ影響します)。 git fetch で隠しref(hidden ref)をフェッチしようとすると失敗します。 uploadpack.allowTipSHA1InWant も参照してください。

uploadpack.hideRefs が有効な場合、 upload-pack が非表示の参照の先端にあるオブジェクトを要求するフェッチ要求を受け入れることを許可します(デフォルトでは、そのような要求は拒否されます)。 uploadpack.hideRefs も参照してください。 これが false であっても、クライアントは、 gitnamespaces(7) のマニュアルページの「SECURITY」セクションで説明されている手法を使用してオブジェクトを盗むことができる場合があります。プライベートデータを別のリポジトリに保持することをお勧めします。

upload-pack が、任意の参照先端から到達可能なオブジェクトを要求するフェッチ要求を受け入れることを許可します。 ただし、オブジェクトの到達可能性の計算には計算コストがかかることに注意してください。 デフォルトは false です。 これが false であっても、クライアントは、 gitnamespaces(7) のマニュアルページの「SECURITY」セクションで説明されている手法を使用してオブジェクトを盗むことができる場合があります。 プライベートデータを別のリポジトリに保持することをお勧めします。

upload-pack が任意のオブジェクトを問い合わせる取得要求(fetch request)を受け入れることを許可します。 これは、 uploadpack.allowTipSHA1InWant と uploadpack.allowReachableSHA1InWant を意味します。 true に設定すると両方が有効になり、 false に設定すると両方が無効になります。 デフォルトでは設定されていません。

upload-pack が pack-objects を開始したとき、pack-objects がパックを準備している間は黙っている期間があるかもしれません。 通常は進行状況情報を出力しますが、フェッチに --quiet を使用した場合、 pack-objects はパックデータが開始するまで何も出力しません。 一部のクライアントとネットワークは、サーバーがハングしてあきらめていると見なす場合があります。 このオプションを設定すると、 upload-pack は uploadpack.keepAlive 秒ごとに空のキープアライブパケットを送信するように指示されます。 このオプションを0に設定すると、キープアライブパケットが完全に無効になります。 デフォルトは5秒です。

このオプションが設定されている場合、 upload-pack がクライアントのパックファイルを作成するために git pack-objects を実行しようとすると、代わりにこのシェルコマンドが実行されます。 pack-objects コマンドとそれが実行するであろう引数(最初の git pack-objects を含む)がシェルコマンドに追加されます。 フックのstdinとstdoutは、 pack-objects 自体が実行されたかのように扱われます。 つまり、 upload-pack は、 pack-objects を対象とした入力をフックに送り、stdoutで完成したpackfileを期待します。

このオプションが設定されている場合、 upload-pack は部分クローン(partial clone)および部分フェッチオブジェクト(partial fetch object)のフィルタリングをサポートします。

未指定のオブジェクトフィルターのデフォルト値を提供します(下記構成変数参照)。 true に設定すると、将来追加されるすべてのフィルターも有効になります。 デフォルトは true です。

<filter> に対応するオブジェクトフィルターを明示的に許可または禁止します。ここで、<filter> は次のいずれかになります: blob:none, blob:limit, object:type, tree, sparse:oid, combine 。 組み合わフィルターを使用する場合は、combine とすべてのネストされたフィルターの種類の両方を許可する必要があります。 デフォルトは uploadpackfilter.allow です。

<n> が uploadpackfilter.tree.maxDepth の値以下の場合にのみ、 --filter=tree:<n> を許可します。 設定されている場合、この構成変数がすでに設定されていない限り、これは uploadpackfilter.tree.allow=true も意味します。 設定されていない場合は効果がありません。

このオプションが設定されている場合、 upload-pack はプロトコルバージョン2の fetch コマンドの ref-in-want 機能をサポートします。 この機能は、レプリケーションの遅延のために、refが指すOIDについて同じビューを持たない可能性がある負荷分散サーバーの利益を目的としています。

この値で始まるURLは、代わりに<base>で始まるように書き換えられます。 あるサイトが多数のリポジトリを提供し、それらを複数のアクセス方法で提供しており、一部のユーザーが異なるアクセス方法を使用する必要がある場合、この機能は、ユーザーが任意の同等のURLを指定し、Gitが自動的に特定のユーザーにとって最適な代替URLに書き換えることを可能にします。 複数の insteadOf 文字列が特定のURLに一致する場合、最も長い一致が使用されます。

この値で始まるURLはプッシュされません。代わりに、<base>で始まるように書き直され、結果のURLがにプッシュされます。 あるサイトが多数のリポジトリを提供し、それらを複数のアクセス方法で提供し、そのうちのいくつかはプッシュを許可しない場合、この機能は、サイト上で見たことのないリポジトリであっても、プル専用のURLを指定して、Gitが自動的に適切なURLを使ってプッシュすることを可能にします。 複数の pushInsteadOf 文字列が特定のURLに一致する場合、最も長い一致が使用されます。 リモートに明示的な pushurl がある場合、Gitはそのリモートのこの設定を無視します。

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 環境変数によってオーバーライドできます。

user.email と user.name のデフォルトを推測しようとせず、代わりに構成からのみ値を取得するようにGitに指示します。 たとえば、複数のメールアドレスがあり、リポジトリごとに異なるアドレスを使用する場合、 グローバル設定でこの設定オプションを true に設定し、名前を指定すると、 Gitは、新しく複製されたリポジトリで新しくコミットを行う前に、電子メールを設定するように求めるプロンプトを表示します。 デフォルトは`false`です。

git-tag(1) または git-commit(1) が、署名されたタグまたは署名されたコミットを作成するときに自動的に必要なキーを選択していない場合、この変数でデフォルトの選択を上書きできます。 このオプションは変更されずに gpg の --local-user パラメータに渡されるため、gpg がサポートする任意の方法を使用してキーを指定できます。 gpg.formatが ssh に設定されている場合、 ssh-agent を使用したときの秘密鍵または公開鍵へのパスを格納することができます。 あるいは、 key:: で始まる公開鍵を直接含めることもできます(例: key::ssh-rsa XXXXXX identifier)。 秘密鍵は、ssh-agent 経由で入手できる必要があります。 設定されていない場合、 Git は gpg.ssh.defaultKeyCommand(例: ssh-add -L) を呼び出し、利用可能な最初のキーを使用しようとします。 下位互換性のために、 key::ssh-rsa XXXXXX identifier などの ssh- で始まる生の鍵は key::ssh-rsa XXXXXX identifier として扱われますが、この形式は非推奨です。 代わりに key:: 形式を使用してください。

versionsort.suffix の非推奨のエイリアス。 versionsort.suffix が設定されている場合は無視されます。

linkgit:git-tag [1]でバージョンの並べ替えが使用されている場合でも、基本バージョンが同じで接尾辞が異なるタグ名は辞書式順序で並べ替えられます。 例えば、メインリリースの後に表示されるプレリリースタグ(例: 1.0 の後の 1.0-rc1)。 この変数を指定して、異なる接尾辞を持つタグのソート順を決定できます。

一部のコマンドで使用できるWebブラウザを指定します。 現在、 git-instaweb(1) と git-help(1) のみが使用できます。

ブランチが指定されておらず、 -b や ` -B` や --detach のいずれも使用されていない場合、 git worktree add はデフォルトでHEADから新しいブランチを作成します。 worktree.guessRemote がtrueに設定されている場合、 worktree add は、名前が新しいブランチ名と一意に一致するリモート追跡ブランチを見つけようとします。 そのようなブランチが存在する場合、それはチェックアウトされ、新しいブランチの「アップストリーム」として設定されます。 そのような一致が見つからない場合は、フォールバックして現在のHEADから新しいブランチを作成します。