mailmap.filegitの config オプションを使用しようとしています。ただし、パスはシェル展開されていないため$HOME/.mailmap、 or ~/.mailmap. ドットファイルを homesick などと同期させていて、Windows、OS X、Linux で同じ .gitconfig を使用している場合、これは非常に厄介です。
私は git のバグトラッカーを見つけることができず、git メーリングリストにそのようなものをスパムで送信したくありません。このバグや軽微な問題はどのように報告すればよいですか?
コードグーグルgit-coreで述べられているように（そしてコメントのチャールズベイリーによって、 git-scmコミュニティページを指しています）：
Gitコミュニティに関する質問やコメントは、電子メールアドレスgit@vger.kernel.orgを使用してメーリングリストに送信できます。バグレポートはこのメーリングリストに送信する必要があります。
2020年第2四半期を更新すると、実際のgit bugreportコマンドが作成されます（以下の最後を参照）
2015年の更新：最新のリファレンスはGitコミュニティページのままです。smoothgripsがコメントで指摘しているように、次のように言及しています。
サブスクライブする必要はありません。返信でCcされます。
返信するときは、Ccリストをそのままにしておいてください（「全員に返信」を使用してください）。
グレイリストを作成すると、最初の投稿が数時間遅れる場合があります。
メールサーバーは「永続的に失敗した」メッセージを含むHTMLメッセージを拒否するため、プレーンテキストを使用することに注意してください。
コミュニティページでは、「バグを効果的に報告する方法」も指摘されています...
パッチを提供したい場合は、に進んでください。これは、パッチ送信プロセスrtyley/submitgitに従うのに役立ちます。
でプルリクエストを作成すると
github.com/git/git/、submitGitパッチを正しくフォーマットして、メーリングリストに送信できます。
議論はリストのどこにとどまりますが、少なくともその最初のステップは少し簡単です。
アップデート2015：Git For Windowsは現在GitHub（github.com/git-for-windows）にあり、ごく最近のリリースである2.4.2+を生成します。
Msysgitは、 msys2 64ビットを使用して段階的に廃止され、その結果git-for-windows.github.io、古い、現在は廃止されたmsysgit.github.ioの代わりになります。
GitHubミラーリポジトリイメージgit/gitはありますが、残念ながら、問題やプルリクエストには使用できません。
アップデート2019：submitGit代替手段があります:( GitGitGadget）gitgitgadget.github.io、Git 2.22（2019年第2四半期）に記載されています
Jeff King（）によるcommit c3a7dd7（2019年3月12日）を参照してください。（濱野純雄による合併---コミット2d33728、2019年4月9日）peff
gitster
プルリクエスターを
GitGitGadget
GitHubでプルリクエストを開く人々が見る寄稿ガイドとPRテンプレートで
submitGitは、メーリングリストを理解するための代替手段を提供するツールについて言及しています。
最近では同様のGitGitGadgetツールもありますが、これもオプションであることを明確にする必要があります。両方のツールについて引き続き言及することもできますが、ユーザーが選択肢に圧倒されるのを避けるために、どちらかを選択することをお勧めします。
結局のところ、ここでの目的の1つは、初めての、またはまれな貢献者の摩擦を減らすことです。そして、好む理由がいくつかあります
GGG：
submitGitまだいくつかの荒いエッジがあるようです。たとえば、スレッド化されたメールリーダーが順不同の配信を処理するのを支援するためにタイムスタンプを変更しません。- 主観的に
GGGは、最近、特にリストの常連によって、リストでより一般的に使用されているようです。GGGより活発な開発が行われているようです（ポイント2に関連している可能性があります）。
submitGitそれでは、実際にに交換してみましょうGGG。
そこにいる間にGGG、PRテンプレートにページへの別のリンクを配置しましょう。これは、このページについて初めて学習するユーザーが行きたい場所だからです。続きを読む。
Git 2.25（2020年第1四半期）には、オブジェクトの列挙に関するチュートリアルがあり、バグを提供/テスト/報告する方法の良い例を提供します。
Emily Shaffer（）によるcommit e0479fa（2019年10月11日）を参照してください。（ Junio C Hamanoによってマージされました---コミット15d9f3d、2019年11月10日）nasamuffin
gitster
documentation：オブジェクトウォーキングのチュートリアルを追加サインオフ：エミリーシェイファー
支援：エリックサンシャイン
オブジェクトウォークに関する既存のドキュメントは、主に、手順に既に精通している人のためのリファレンスとして意図されているようです。
このチュートリアルでは、いくつかの必要最低限のオブジェクトウォークの入門レベルのガイドを提供し、新しいGit寄稿者が、オプションの解析や特別なケーシングを通り抜けることなく概念を学習できるようにします。ターゲットオーディエンスは、オブジェクトウォーキングの概念を始めたばかりのGit寄稿者です。
目標は、この寄稿者がリビジョンウォークを実行する既存のコマンドをより簡単に理解して変更できるようにすることですが、ウォークを実行する新しいコマンドを作成するための寄稿者も準備します。このチュートリアルでは、オブジェクトウォーク、基本的なコミットウォークの設定、基本的な全オブジェクトウォークの設定、および両方のウォークタイプへの構成変更の追加に関連する構造体の基本的な概要について説明します。
新しいコマンドを作成する方法や、コマンドラインまたはgitconfigsからオプションを検索する方法については意図的に説明していません。https://github.com/nasamuffin/git/tree/revwalkには、このチュートリアルで生成されたコードのリファレンス実装を含む関連パッチセットがあります。
注：チュートリアルはGit 2.27（2020年第2四半期）で修正されました。
Johannes Schindelin（）によるcommit e3f53ce（2020年3月28日）を参照してください。（濱野純雄による合併---コミット7780604、 2020年4月22日）dscho
gitster
MyFirstObjectWalk：不要な条件文を削除サインオフ-作成者：Johannes Schindelin
レビュー者：Emily Shaffer
与えられた例では、
commitはできませんNULL（これはループ条件であるためです。そうであったNULL場合、ループ本体はまったく入力されません）。したがって、これがデッドコードであることを確認するのに、この開発者は1、2時間かかりました。将来の読者を困惑させないように、それを削除しましょう。
Git 2.25（2020年第1四半期）では、GitGitGadgetが文書化されています。
Emily Shaffer（）によるcommit 3c8d754、commit 3ada78d、commit 4ed5562（2019年10月31日）を参照してください。（ Junio C Hamanoによってマージされました---コミットf089ddd、2019年12月1日）nasamuffin
gitster
myfirstcontrib：gitgitgadgetallowerを見つけるためのヒントサインオフ-作成者：Emily Shaffer
Gitに対するプルリクエストをGit-mailing-list-friendly-patch-emailsに変換するための便利なツールであるGitGitGadgetは、スパム対策として、すべての新規ユーザーが
/allow既存のユーザーによって「」されてから、その新しいユーザーに対して何かを行う必要があります。ユーザー。このチュートリアルではそのメカニズムについて説明しましたが、新しいプルリクエストを許可する人を見つける方法についてはあまりヒントがありませんでした。
したがって、新しいGitGitGadgetユーザーに、自分の名前をリストに追加できる人を探す場所を教えてください。このパッチのアドバイスは、GitGitGadgetに提案されたアドバイスに基づいています：
gitgitgadget/gitgitgadgetPR 138
Git 2.25（2020年第1四半期）では、メーリングリストのアーカイブとnntpサービスのドキュメントが更新されています。
ジェフキング（）によるコミット3eae30e、コミット46c6749（2019年11月27日）を参照してください。（ Junio C Hamanoによってマージされました---コミット3b3d9ea、2019年12月6日）peff
gitster
doc：public-inboxリンクをlore.kernel.orgに置き換えますサインオフ-作成者：Jeff King
現在推奨している
lore.kernel.orgので（そしてpublic-inbox.orgドメインが最終的になくなる可能性があるため）、それを使用するように内部参照も更新しましょう。
それは私たちの参照を将来にわたって保証し、人々に従わせたい模範を示します。
「このリストは現在、lore.kernel.org/git」にもアーカイブされています。を参照してください。
doc：MARCリンクをlore.kernel.orgに置き換えますサインオフ：Denton Liu
現在、lore.kernel.orgを推奨しているので、marc.infoリンクをlore.kernel.orgに置き換えます。
MARCは長い間存在していましたが、永遠に続くものはありません（Gmaneを参照）。
MARCは不透明なメッセージ識別子を使用するため、lore.kernel.orgに切り替えることは厳密な改善であるはずです。これは、lore.kernel.orgがダウンした場合でも、Message-IDにより、将来の読者が他のアーカイブで参照されているメッセージを検索できるようになるためです。
README.md将来のメッセージをリンクするためだけでなく、個人的に読むための完全に優れたメールアーカイブであるため、MARCへの参照を1つ残しておきます。
と：
RelNotes：Gmaneを実際のメッセージIDに置き換えますサインオフ：Denton Liu
残っているGmaneへの唯一の参照はRelNotesにあります。
これらは確かに積極的に使用されていませんが、将来の読者にとって歴史的に興味深いかもしれないので、メール参照がより堅牢であることを確認しましょう。Gmaneへのリンクを
lore.kernel.org（これは新しい優先メーリングリストアーカイブであり、URLにMessage-IDが含まれています）へのリンクに置き換え、裸のGmaneID参照をMessage-IDに置き換えます。メッセージIDは、 https：//public-inbox.org/git/
gmane:<id>で「 」を検索し、結果のメッセージを取得することで見つかりました。
そしてに関してlkml.org：
doc：LKMLリンクをlore.kernel.orgに置き換えますサインオフ：Denton Liu
現在、lore.kernel.orgを推奨しているため、LKMLリンクをlore.kernel.orgに置き換えます。
LKMLは長い間存在していましたが、永遠に続くものはありません（Gmaneを参照）。LKMLは不透明なメッセージ識別子を使用するため、メッセージIDがダウンした場合でも、将来の読者が他のアーカイブで参照されているメッセージを検索できるようになるため
、切り替えlore.kernel.orgは厳密に改善する必要があります。lore.kernel.org
Git 2.26（2020年第1四半期）では、新しい寄稿者向けのドキュメントが増えています。
commit a2dc434（2020年2月14日）およびEmily Shaffer（）によるcommit 4bb4fd4（2020年1月24日）を参照してください。（ Junio C Hamanoによってマージされました---コミット325eb66、2020年2月25日）nasamuffin
gitster
MyFirstContribution：助けを得るための手段を追加するサインオフ-作成者：Emily Shaffer
https://lore.kernel.org/git/20191114194708.GD60198@google.com/を使用すると、メンタリングメーリングリストが作成され、質問がある新しい寄稿者に転送する必要があります。
#git-develGitの貢献者を対象とした言及。一緒に最初の貢献を得るのに助けを求めることは、そのチャネルのトピックです。また、人々がIRCに慣れていない場合に備えて、いくつかの規則についても言及してください。メンタリングリスト
#git-develは両方ともGit寄稿者のサブセットであるため、最後にメインのGitリストをリストし、投稿規則のいくつかに言及します。
と：
MyFirstContribution：連絡先情報を言い換えるサインオフ-作成者：Emily Shaffer
レビュー者：Jonathan Nieder
新規ユーザーがgit@vger.kernel.orgに質問を送信するのを思いとどまらせないように努め、メインリストとは対照的にメンタリングリストの目的を説明してください。
Git 2.27（2020年第2四半期）では、バグを報告する前に、（新しい）FAQをお読みください。
ブライアンmによるコミット2149b67（2020年3月30日）を参照してください。カールソン（bk2204）。
（濱野純雄による合併gitster---コミット06aaafb、 2020年4月22日）
docs：FAQを追加するサインオフ-作成者：brianm。カールソン
Gitは、非常に柔軟で強力なソフトウェアです。
ただし、多くのユーザーにとっては威圧的である可能性があり、ユーザーがよく尋ねる一連の一般的な質問があります。
すでにいくつかの新しいユーザードキュメントがありますが、ユーザーがよくある質問に対処するためにFAQを追加する価値があります。
この一部はドキュメントの他の場所で取り上げられていますが、経験上、ユーザーが見つけるのは難しいことがわかっているため、一元化された場所が役立ちます。
そのようなFAQを追加し、いくつかの一般的な質問と回答を記入してください。現在、エントリはほとんどありませんが、将来的には、ユーザーからの新しい質問が見つかったときに、さらに多くのことをカバーするように拡張することができます。
FAQは、独立したソフトウェアとしてのGitだけでなく、人々が使用するCIツールとホスティングプロバイダーのエコシステムにも当てはまる一般的な構成の質問にも対応しています。これらは一般的な質問のソースであるためです。
Git 2.27（2020年第2四半期）では、「バグレポート」ツールを使用できます。
Emily Shaffer（）によるcommit 8f0e984 （ 2020年4月27日）、およびcommit 69bcbbc、commit 1411914、commit 617d571、commit 238b439、commit 709df95（2020年4月16日）を参照してください。（濱野純雄による合併---コミットdd094c2、2020年5月1日）nasamuffin
gitster
bugreport：デバッグ情報を生成するツールを追加サインオフ-作成者：Emily Shaffer
再現手順、予想される動作、実際の動作など、適切なバグレポートをユーザーに求める方法をGitに教えます。後で、Gitはリポジトリからいくつかの診断情報を収集する方法を学ぶことができます。
ユーザーが、そうでなければユーザーに尋ねる必要のある診断情報を含む、よく書かれたバグレポートを送信できれば、レポーターとGit寄稿者の間の質疑応答の往復回数を減らすことができます。
ユーザーは、リポジトリを混乱した状態にした場合、このようなレポートをローカルの「Gitエキスパート」に送信することもできます。
git bugreportドキュメントには次のものが含まれます。
git bugreport [(-o | --output-directory) <path>] [(-s | --suffix) <format>]
説明
ユーザーのマシン、Gitクライアント、リポジトリの状態に関する情報、およびユーザーが観察した動作に関する情報を要求するフォームを1つのテキストファイルにキャプチャします。このファイルは、ユーザーがGitメーリングリストなどで順番に共有できます。観察されたバグを報告します。
次の情報がユーザーから要求されます。
- 複製手順
- 予想される行動
- 実際の動作
Git 2.27（2020年第2四半期）で、" git bugreport"はリポジトリ内の有効なフックを報告することを学びました。
Emily Shaffer（）によるcommit 788a776（2020年5月8日）を参照してください。（濱野純雄による合併---コミット3583730、2020年5月14日）nasamuffin
gitster
bugreport：入力されたフックのリストを収集しますサインオフ-作成者：Emily Shaffer
時折、ユーザーが見ている障害は、おそらくユーザーが気付かないうちに、実行されている特定のフックに関連している可能性があります。
フックの内容は機密性が高く、ユーザーデータやユーザーの組織に固有のプロセス情報が含まれている場合がありますが、フックが特定の段階で実行されていることを知っているだけで、問題が発生しているかどうかを理解できます。コード内にフック名の明確なリストがない場合は、ドキュメントから独自のリストをコンパイルします。これはビットロットになりやすい可能性がありますが、許容できるフックの信頼できる唯一の情報源を設計することは、バグレポートツールへのこの小さな変更にはオーバーヘッドが大きすぎます。
Git 2.28（2020年第3四半期）では、" git bugreport"はどのシェルが使用されているかを報告することを学びます。
Emily Shaffer（）によるcommit 4a4804e、commit 39f4919（2020年5月12日）を参照してください。（ Junio C Hamanoによってマージされました---コミットce095ec、2020年6月9日）nasamuffin
gitster
help：シェルパスをに追加--build-optionsサインオフ-作成者：Emily Shaffer
シェルベースのGitコマンドが失敗した場合に、どのシェルGitがポイントを試みるように構築されたかを知ることは有用かもしれません。
$SHELL_PATHはビルド中に設定され、マンページビューアの起動に使用されます。また、によってgit-compat-util.h使用され、テスト中に使用されます。
'git version --build-options'はバグレポートでの使用が推奨されているため、この情報をそこに含めることは理にかなっています。
と：
bugreport：ユーザーインタラクティブシェルを含めるサインオフ-作成者：Emily Shaffer
オートコンプリートやシェルプロンプトなど、Gitがインタラクティブシェルと対話する方法についてユーザーが不満を言う可能性があります。その場合、インタラクティブに使用しているシェルを知ることは私たちにとって有用です。
レビューコメントに応答した後の元の寄稿者がパッチアップデートで説明を使用することへの期待は、Git 2.30（Q1 2021）で説明されています。
Junio C Hamano（）によるcommit a6d8d11（2020年11月20日）を参照してください。（ Junio C Hamanoによってマージされました---コミットb94b1f9、2020年11月30日）gitster
gitster
MyFirstContribition：質問に答えることは話の終わりではありませんレビュー投稿者：Emily Shaffer
レビュー交換は、レビュー担当者が「ログメッセージ（またはここのドキュメント）のこのフレーズは何を意味しましたか？」と尋ね、作成者が意味を答えてから、レビュー担当者が「ああ、それはあなたが何をしているのか」と言うことから始まります。つまり、ロジックの流れは理にかなっています。」
しかし、それは話の幸せな終わりではありません。
新しい寄稿者は、上記の交換でレビューされた資料が、更新されるまで、それを読む次の人と同じようにまだ不明確であることを忘れがちです。私たちが近くにいる間、レビューアによるコメントを参照するために使用される動詞「request」を「suggest」に言い換えます---これは、同じ段落の後半に表示される「original」と「suggested」の対比と一致します。著者がレビューアの希望を喜ばせるのではなく、レビューアが単に著者がコミットを磨くのを助けているだけであることを明確にします。変更を提案した、オリジナルの方が良いと感じた、またはコメント
MyFirstContribution現在、そのマニュアルページに含まれています：
レビューアは、提案されたコミットログメッセージまたは変更自体のいずれかで、パッチセットに何を書き込んだかについて質問する場合があります。応答メッセージでこれらの質問に答える必要がありますが、多くの場合、レビュー担当者があなたが何を書くつもりかを理解するためにこれらの質問をした理由は、パッチセットを理解するために説明が必要だったためです。
あなたの回答で彼らの質問に答えるだけで満足しないでください、そして彼らがあなたが言いたいことを今理解していると彼らが言うのを聞いてください。パッチを更新して、レビュー担当者が問題を抱えていたポイントを明確にし、v2を準備します。レビューアの質問に答えるためにv1を説明するために使用した単語は、使用すると便利な場合があります。あなたの目標は、v2を十分に明確にして、次に読む人に同じ説明をする必要がなくなるようにすることです。
Git 2.30（Q1 2021）では、非再入可能の使用localtime()が削除されました。
Taylor Blau（）によるcommit 4f6460d（2020年11月30日）を参照してください。（ Junio C Hamanoによってマージされました---コミットbb48056、2020年12月8日）ttaylorr
gitster
builtin/bugreport.c：スレッドセーフを使用するlocaltime_r()サインオフ-作成者：Taylor Blau
そのファイル名を生成するために、'
git bugreport' （man）ビルトインはシステムに現在の時刻を'localtime()'で要求します。
これは共有バッファを使用するため、スレッドセーフではありません。'
git bugreport' （man）はマルチスレッドではありませんが、を使用localtime()すると、いくつかの静的分析ツールが文句を言うようにトリガーされる可能性があります。$ git grep -oh 'localtime\(_.\)\?' -- **/*.c | sort | uniq -cは、スレッドセーフでない「localtime」の唯一の使用法がドキュメントの一部にあることを示しています。
したがって、このインスタンスを変換して、一貫性を保つためにスレッドセーフバージョンを使用し、いくつかの分析ツールを緩和します。
git bugreport標準テンプレートを使用して電子メール本文を作成するために使用します。
生成されたテキスト ファイルをコピーしてメール本文に貼り付け、git@vger.kernel.org に送信します。必ずプレーン テキストで送信してください。HTML は戻ってきます。( GMail を使用している場合は、 https: //www.dummies.com/software/other-software/10-useful-gmail-settings/ を参照してください)。