一部のオープンソースプロジェクトがプルリクエストを受け付けないのに、パッチファイルのみをメールで送信するのはなぜですか

一部のオープンソースプロジェクトがプルリクエストを受け付けないが、パッチファイルのみをメールで送信する必要があるのはなぜですか？例：Git githubまたは他の分散scmホスティングでコードを公開しますが。パッチファイルを送信することは、インタラクティブでも便利でもありません。パッチファイルは昔ながらの方法です。プルリクエストはインタラクティブです。他の人も議論するかもしれません。

プルリクエストの受け入れを誰が担当するかによります。

Linus Torvaldsの場合、よく... 古き良きパッチが望ましい：

githubのプルリクエストは行いません。

githubは、プルするように求めている人の有効なメールアドレスさえ持っているなど、関連するすべての情報を破棄します。
diffstatも不十分で役に立たない。

Gitには優れたプルリクエスト生成モジュールが付属していますが、代わりにgithubが独自の完全に劣ったバージョンに置き換えることにしました。
その結果、私はgithubがこれらの種類のことには役に立たないと考えています。

それのための罰金ホスティングが、プル要求とオンラインで編集しコミットし、ただ純粋なゴミです。
私はgithubの人々に私の懸念について話したが、彼らは彼らが重要であるとは思わなかったので、私はあきらめた。githubにバグレポートを作成してください。

彼の詳細：

ためには、私はgithubから引っ張って、あなたがする必要があります。

• （a）githubがプルを要求するときに行う、脳にダメージを与えたがらくたではなく、実際のプル要求を行います。
  • 実際の説明、
  • 適切なメールアドレス、
  • 適切なショートログ、そして
  • 適切diffstat。
• （b）githubのIDはランダムであるため、プルリクエストは署名されたタグであることが期待されるため、問題の人物のIDを確認できます。

また、github Webインターフェースで行われたコミットをプルすることも拒否します。
繰り返しますが、その理由は、github Webインターフェースの動作方法、それらのコミットは常に純粋なくだらないことです。
githubで行われたコミットは、まったく読めない記述を常に持っています。なぜなら、githubのコミットを行うことは、カーネルの人々がコミットメッセージから期待する最も単純なことを何もしないからです。

• 「最初の行の短い1行の説明」なし
• 入力する長い説明の正しい折り返しはありません：githubのコミットメッセージは（説明がある場合は）1行の読み取り不能な行になる傾向があります。
• カーネルの提出に必要なサインオフなどはありません。

github を使用すると、適切なコミットメッセージを簡単に記述でき、適切な「ショートgitkログの1 ライナー」および「フルログの完全な説明」を強制できます。
しかし、githubはそうではありません。
代わりに、githubの「Webでコミット」インターフェースは、見栄えの良いメッセージを書くためのまったく正気な方法を備えていない1つの恐ろしいテキスト入力フィールドです。

コミットメッセージのテキスト領域でチャレンジされた場合：

@torvalds GitHubのコミットUIは、コミットメッセージ用のテキスト領域を提供します。
これにより、新しい行がサポートされ、適切にフォーマットされたコミットメッセージを簡単に実行できるようになります。

いいえ、そうではありません。
サポートしているのは、長い行を書くことで、その長さがわからない。
テキスト領域では改行は行われず、改行がどこに行くかを判断する方法はありません。

言い換えれば、「きちんとフォーマットされたコミットメッセージ」を実行することを非常に難しくしています。
また、ささいな「ショートログのoneliner」モデルを強制しません。そのため、コミットメッセージはショートログとgitkで完全にがらくたに見えることがよくあります。

したがって、github commit UIには

• 別の「ショートログ」ワンライナーテキストウィンドウを使用して、ユーザーがそれを台無しにできないようにします。
• 実際に標準の72列マークで正常なワードラップを行う方法。
• 一部のプロジェクトはプロジェクト固有の、または法的理由でさえ必要であるというサインオフなどに関するリマインダー。