は.mailmap、作業ツリーのルートレベルからのみ読み取られるように文書化されていますが、ベアリポジトリ内の漂遊ファイルも誤って読み取られ、Git 2.31(Q1 2021)で修正されています。
Jeff King()によるcommit a38cb98(2021年2月10日)を参照してください。( Junio C Hamanoによってマージされました---コミット9bdccbc、2021年2月17日)peff
gitster
mailmap.mailmap:作業ツリーでのみ検索
サインオフ-作成者:Jeff King
ファイルを検索しようとすると、.mailmap常に現在のディレクトリでファイルが検索されます。
これは、起動時に常に最上位ディレクトリに移動するため、作業ツリーのあるリポジトリでは意味があります。
しかし、裸のリポジトリの場合、混乱する可能性があります。
--git-dirのような(または$GIT_DIR環境内の)オプションを使用すると、まったく読み取りを行わず、 Gitを起動する前にたまたまそこにあったディレクトリからchdir読み取ります。.mailmap
(--git-dir歴史的に作業ツリーを指定しないということは、現在のディレクトリが作業ツリーのルートであることをcore.bare意味しますが、ほとんどのベアリポジトリは最近設定されているため、作業ツリーがまったくないことに気付くでしょう)。
gitmailmap(5)のドキュメントには次のように書かれています。
If the file `.mailmap` exists at the toplevel of the repository[...]
これは同様に、作業ツリーで見ているという概念を強化します。
このパッチは、私たちが裸のリポジトリにいるときにそのようなファイルを探すことを防ぎます。
これは、以前は機能していたものを壊します。
cd bare.git
git cat-file blob HEAD:.mailmap >.mailmap
git shortlog
しかし、それはドキュメントで宣伝されたことはありません。
そして最近では、同じことをはるかにクリーンな方法で実行する必要がmailmap.blobあります(デフォルトは)。HEAD:.mailmap
ただし、もう1つ興味深いケースがあります。それは、リポジトリがまったくない可能性があるということです。(man)コマンドは、そのstdinに出力をフィードして実行でき、メールマップを適用します。
その場合、現在のディレクトリから読み取ることはおそらく理にかなっています。
このパッチは引き続きそうします。git-shortloggit-log
.mailmap
これはさらに奇妙なケースにつながります。stdingit-shortlogを処理するために実行した場合、入力は完全に別のリポジトリからのものである可能性があります。
では、ツリー内を尊重する必要があり.mailmapますか?おそらくそうだ。
入力のソースが何であれ、shortlogがリポジトリで実行されている場合、ドキュメントには.mailmap、トップレベルから読み取ったと記載されています(もちろん、同じリポジトリからのものである可能性が非常に高く、ユーザーは(man)を実行し、何らかの理由で個別に実行します)。git-loggit-shortlog
含まれているテストはこれらのケースをカバーしており、「レポなし」のケースを明示的に文書化しています。
.mailmapまた、作業ツリーのサブディレクトリで開始した場合でも、トップレベルの「」が見つかることを確認するテストを追加します。
これは、このコミットの前後の両方で機能しましたが、明示的にテストしたことはありません(chdir作業ツリーがある場合は、常に最上位に移動するため、機能します)。
git shortlog現在、そのマニュアルページに含まれています:
git shortlogリポジトリの外部で実行された場合(標準入力でログの内容を処理するため)、.mailmap現在のディレクトリでファイルが検索されることに注意してください。