¿Por qué algunos proyectos de código abierto no aceptan solicitudes de extracción, sino solo enviar archivos de parche por correo electrónico?

¿Por qué algunos proyectos de código abierto no aceptan solicitudes de extracción, sino que solo requieren contribuyentes para enviar archivos de parches por correo electrónico? por ejemplo, Git Aunque publican código en github u otro alojamiento distribuido de scm No es interactivo ni conveniente enviar archivos de parches. El archivo de parche es una forma anticuada. Las solicitudes de extracción son interactivas. Otras personas también pueden discutir.

Puede depender de quién estará a cargo de aceptar su solicitud de extracción.

Si es Linus Torvalds , bueno ... es preferible un buen parche viejo :

No hago solicitudes de extracción de github.

Github desecha toda la información relevante, como tener incluso una dirección de correo electrónico válida para la persona que me pide que retire .
El diffstat también es deficiente e inútil.

Git viene con un buen módulo de generación de solicitud de extracción, pero en su lugar, github decidió reemplazarlo con su propia versión totalmente inferior.
Como resultado, considero que github es inútil para este tipo de cosas.

Está bien para el alojamiento , pero las solicitudes de extracción y la edición de confirmación en línea son simplemente basura.
Le dije a la gente de Github acerca de mis preocupaciones, no pensaron que importaran, así que me di por vencido. Siéntase libre de hacer un informe de error a github.

Él detalla:

Para que yo pueda sacar de github, necesitas:

• (a) haga una solicitud de extracción real, no la basura dañada por el cerebro que hace github cuando le pide que solicite una extracción:
  • explicación real ,
  • direcciones de correo electrónico adecuadas ,
  • shortlog adecuado , y
  • diffstat adecuado .
• (b) dado que las identidades de github son aleatorias, espero que la solicitud de extracción sea una etiqueta firmada , de modo que pueda verificar la identidad de la persona en cuestión.

También me niego a realizar commits que se han realizado con la interfaz web de Github.
Una vez más, la razón de esto es que la forma en que funciona la interfaz web de Github, esos commits son invariablemente basura.
Los commits realizados en github siempre tienen descripciones totalmente ilegibles, porque el commit de github no hace ninguna de las cosas más simples que la gente del núcleo espera de un mensaje de commit:

• sin "descripción breve de una línea en la primera línea"
• sin ajuste de palabra sensato de la descripción larga que escribe: los mensajes de confirmación de github tienden a ser (si tienen alguna descripción) una larga línea ilegible.
• sin firmas, etc. que requerimos para las presentaciones del núcleo.

github podría facilitar la redacción de buenos mensajes de confirmación y aplicar el "oneliner adecuado para los registros cortos y gitkla explicación completa para los registros completos".
Pero github no lo hace.
En cambio, la interfaz de github "commit on the web" es un campo de entrada de texto horrible y absolutamente imposible de escribir un mensaje atractivo.

Cuando se le solicita en el área de texto para enviar mensajes:

@torvalds La interfaz de usuario de confirmación de GitHub proporciona un área de texto para los mensajes de confirmación.
Esto admite nuevas líneas y facilita la creación de mensajes de confirmación con un formato agradable :)

No, no lo hace.
Lo que admite es escribir largas líneas que no tienes ni idea de cuánto duran.
El área de texto no hace saltos de línea por usted y no tiene forma de juzgar dónde irían los saltos de línea.

En otras palabras, hace que sea muy difícil hacer "mensajes de confirmación bien formateados".
Tampoco aplica el trivial modelo "oneliner para shortlog" , por lo que los mensajes de confirmación a menudo terminan pareciendo basura en shortlogs y en gitk.

Entonces, la interfaz de usuario de commit de github debería tener

• ventana de texto de un solo trazo "shortlog" separada, para que la gente no pueda arruinar eso.
• alguna forma de hacer un buen ajuste de palabras en la marca estándar de 72 columnas.
• recordatorios sobre las aprobaciones, etc. que algunos proyectos necesitan por razones específicas del proyecto o incluso legales.