Warum akzeptieren einige Open Source-Projekte keine Pull-Anfragen, sondern senden nur Patch-Dateien per E-Mail

Warum akzeptieren einige Open Source-Projekte keine Pull-Anfragen, sondern verlangen von den Mitwirkenden, dass sie nur Patch-Dateien per E-Mail versenden? zB Git Obwohl sie Code in Github oder einem anderen verteilten SCM-Hosting veröffentlichen. Das Senden von Patch-Dateien ist weder interaktiv noch bequem. Patch-Datei ist ein altmodischer Weg. Pull-Anforderungen sind interaktiv. Andere Leute können auch diskutieren.

Es kann davon abhängen, wer für die Annahme Ihrer Pull-Anfrage zuständig ist.

Wenn es Linus Torvalds ist , ist ein guter alter Patch vorzuziehen :

Ich mache keine Github Pull-Anfragen.

github wirft alle relevanten Informationen weg, zum Beispiel eine gültige E-Mail-Adresse für die Person, die mich zum Ziehen auffordert .
Der Diffstat ist auch mangelhaft und unbrauchbar.

Git kommt mit einem netten Pull-Request-Generierungsmodul, aber Github entschied sich stattdessen dafür, es durch eine eigene, völlig minderwertige Version zu ersetzen.
Infolgedessen halte ich Github für nutzlos für diese Art von Dingen.

Es ist in Ordnung für das Hosting , aber die Pull-Anfragen und die Online-Commit-Bearbeitung sind nur Müll.
Ich habe Github-Leuten von meinen Sorgen erzählt, sie dachten nicht, dass sie wichtig sind, also gab ich auf. Fühlen Sie sich frei, einen Bugreport für Github zu erstellen.

Er führt aus:

Damit für mich aus dem Github ziehen kann, musst du:

• (a) Machen Sie eine echte Pull-Anfrage, nicht den Braindamaged Crap, den Github macht, wenn Sie ihn bitten, eine Pull-Anfrage zu stellen:
  • echte Erklärung ,
  • richtige E-Mail-Adressen ,
  • richtiger Shortlog und
  • richtige diffstat .
• (b) Da Github-Identitäten zufällig sind, erwarte ich, dass die Pull-Anforderung ein signiertes Tag ist , damit ich die Identität der betreffenden Person überprüfen kann.

Ich lehne es auch ab, Commits abzurufen, die mit dem Github-Webinterface gemacht wurden.
Der Grund dafür ist wiederum, dass die Funktionsweise des Github-Webinterfaces bei diesen Commits ausnahmslos reine Scheiße ist.
Auf github durchgeführte Commits haben ausnahmslos völlig unlesbare Beschreibungen, da die Github-Commit-Funktion keine der einfachsten Funktionen ausführt, die die Kernel- Benutzer von einer Commit-Nachricht erwarten:

• keine "kurze einzeilige Beschreibung in der ersten Zeile"
• Kein sinnvoller Zeilenumbruch in der langen Beschreibung, die Sie eingeben: Bei Github-Commit-Nachrichten handelt es sich in der Regel (wenn sie überhaupt eine Beschreibung haben) um eine lange, unlesbare Zeile.
• Keine Abmeldungen usw., die wir für Kernelübermittlungen benötigen.

github könnte es einfach machen, gute Commit-Nachrichten zu schreiben und den richtigen "Oneliner für Shortlogs und gitkvollständige Erklärungen für vollständige Logs" zu erzwingen .
Aber Github nicht.
Stattdessen ist die Github-Oberfläche "Festschreiben im Web" ein einziges schreckliches Texteingabefeld, in dem es absolut keinen vernünftigen Weg gibt, eine gut aussehende Nachricht zu schreiben.

Bei Aufforderung im Textbereich für Commit-Nachrichten:

@torvalds Die GitHub-Commit-Benutzeroberfläche bietet einen Textbereich für Commit-Nachrichten.
Dies unterstützt neue Zeilen und macht es einfach, gut formatierte Commit-Nachrichten zu erstellen :)

Nein, tut es nicht.
Was es unterstützt, ist das Schreiben langer Zeilen, von denen Sie keine Ahnung haben, wie lange sie sind.
Der Textbereich führt keine Zeilenumbrüche für Sie aus, und Sie können nicht beurteilen, wohin die Zeilenumbrüche führen würden.

Mit anderen Worten, es ist sehr schwierig, "gut formatierte Commit-Nachrichten" zu erstellen.
Es erzwingt auch nicht das triviale "Oneliner for Shortlog" -Modell , so dass die Commit-Nachrichten in Shortlogs und in Gitk oft wie totaler Mist aussehen.

Also sollte die Github-Commit-UI haben

• Separates "Shortlog" -Einzeiler-Textfenster, damit die Leute das nicht vermasseln können.
• eine Möglichkeit, einen normalen Zeilenumbruch bei der Standardmarkierung von 72 Spalten durchzuführen.
• Erinnerungen an Abmeldungen usw., die einige Projekte aus projektspezifischen oder sogar rechtlichen Gründen benötigen.