Pourquoi certains projets open source n'acceptent-ils pas les demandes de tirage, mais uniquement les fichiers de correctifs par courrier électronique

Pourquoi certains projets open source n'acceptent-ils pas les demandes d'extraction, mais demandent-ils uniquement aux contributeurs d'envoyer des fichiers de correctifs par courrier électronique? par exemple Git Bien qu'ils publient du code dans github ou autre hébergement scm distribué. Il n'est pas interactif ni pratique d'envoyer des fichiers de correctifs. Le fichier de patch est une méthode à l'ancienne. Les demandes de tirage sont interactives. D'autres personnes peuvent également discuter.

Cela peut dépendre de qui sera en charge d'accepter votre demande de pull.

Si c'est Linus Torvalds , eh bien ... un bon vieux patch est préférable :

Je ne fais pas de requêtes pull github.

github jette toutes les informations pertinentes, comme avoir même une adresse e-mail valide pour la personne qui me demande de retirer .
Le diffstat est également déficient et inutile.

Git est livré avec un joli module de génération de demande de pull, mais github a plutôt décidé de le remplacer par leur propre version totalement inférieure.
En conséquence, je considère github inutile pour ce genre de choses.

C'est bien pour l' hébergement , mais les demandes de tirage et l'édition de validation en ligne ne sont que de la pure ordure.
J'ai fait part de mes inquiétudes aux gens de Github, ils ne pensaient pas que cela comptait, alors j'ai abandonné. N'hésitez pas à faire un rapport de bug sur github.

Il détaille:

Pour que je puisse retirer de github, vous devez:

• (a) faites une vraie demande de pull, pas la merde braindamaged que fait Github lorsque vous lui demandez de demander un pull:
  • vraie explication ,
  • adresses e-mail appropriées ,
  • carnet de commandes approprié , et
  • diffstat approprié .
• (b) étant donné que les identités github sont aléatoires, je m'attends à ce que la demande d'extraction soit une balise signée , afin de pouvoir vérifier l'identité de la personne en question.

Je refuse également de tirer des commits qui ont été effectués avec l'interface Web github.
Encore une fois, la raison en est que la façon dont fonctionne l'interface Web de Github, ces commits sont toujours de la merde pure.
Les validations effectuées sur github ont invariablement des descriptions totalement illisibles, car la création de commit github ne fait rien des choses les plus simples que les gens du noyau attendent d'un message de commit:

• pas de "brève description sur une ligne dans la première ligne"
• pas de retour à la ligne de la description longue que vous tapez: les messages de validation github ont tendance à être (s'ils ont une description) une longue ligne illisible.
• aucune approbation, etc., dont nous avons besoin pour les soumissions du noyau.

github pourrait faciliter l'écriture de bons messages de commit et appliquer le bon "oneliner pour les shortlogs et gitkune explication complète pour les logs complets".
Mais pas Github.
Au lieu de cela, l'interface github "commit on the web" est un seul champ de saisie de texte horrible sans aucun moyen sensé d'écrire un bon message.

En cas de défi dans la zone de texte pour les messages de validation:

@torvalds L'interface utilisateur de validation GitHub fournit une zone de texte pour les messages de validation.
Cela prend en charge les nouvelles lignes et facilite la création de messages de validation bien formatés :)

Non, ce n'est pas le cas.
Ce qu'il prend en charge, c'est d'écrire de longues lignes dont vous ne savez pas combien de temps elles sont.
La zone de texte ne fait pas de sauts de ligne pour vous, et vous n'avez aucun moyen de déterminer où iraient les sauts de ligne.

En d'autres termes, il est en effet très difficile de faire des "messages de validation bien formatés".
Il n'applique pas non plus le modèle trivial "oneliner pour shortlog" , donc les messages de commit finissent souvent par ressembler à de la merde totale dans les shortlogs et dans gitk.

Donc, l'interface utilisateur de validation github devrait avoir

• fenêtre de texte séparée "shortlog" à une ligne, de sorte que les gens ne puissent pas bousiller ça.
• un moyen de faire un retour à la ligne sain à la marque standard de 72 colonnes.
• rappels sur les approbations, etc. dont certains projets ont besoin pour des raisons spécifiques au projet ou même juridiques.