Perché alcuni progetti open source non accettano richieste pull, ma inviano solo file di patch via e-mail

Perché alcuni progetti open source non accettano richieste pull, ma richiedono collaboratori solo ai file patch e-mail? ad es. Git Anche se pubblicano codice in github o altri hosting scm distribuito. Non è interattivo né conveniente inviare file patch. Il file patch è un modo vecchio stile. Le richieste pull sono interattive. Altre persone possono anche discutere.

Può dipendere da chi sarà incaricato di accettare la tua richiesta pull.

Se è Linus Torvalds , beh ... è preferibile una buona vecchia patch :

Non faccio richieste pull github.

github elimina tutte le informazioni pertinenti, come avere anche un indirizzo e-mail valido per la persona che mi chiede di estrarre .
Anche il diffstat è carente e inutile.

Git viene fornito con un bel modulo di generazione pull-request, ma github invece ha deciso di sostituirlo con una versione totalmente inferiore.
Di conseguenza, ritengo github inutile per questo tipo di cose.

Va bene per l' hosting , ma le richieste pull e la modifica del commit online sono solo spazzatura.
Ho detto alle persone di Github delle mie preoccupazioni, non pensavano che avessero importanza, quindi ho rinunciato. Sentiti libero di fare una segnalazione bug a github.

Lui dettagli:

In ordine per me per tirare da GitHub, è necessario:

• (a) fai una vera richiesta di pull, non la schifezza di Braithamaged che github fa quando gli chiedi di richiedere un pull:
  • vera spiegazione ,
  • indirizzi email appropriati ,
  • collegamento corretto e
  • diffstat corretto .
• (b) poiché le identità di github sono casuali, mi aspetto che la richiesta pull sia un tag firmato , in modo da poter verificare l'identità della persona in questione.

Mi rifiuto anche di eseguire il commit delle operazioni effettuate con l'interfaccia web di Github.
Ancora una volta, la ragione di ciò è che il modo in cui funziona l'interfaccia web di Github, questi commit sono invariabilmente pure merda.
I commit eseguiti su github invariabilmente hanno descrizioni totalmente illeggibili, perché il commit github che fa cosa non fa nessuna delle cose più semplici che la gente del kernel si aspetta da un messaggio di commit:

• nessuna "breve descrizione di una riga nella prima riga"
• nessun avvolgimento di parole sano della lunga descrizione che scrivi: i messaggi di commit github tendono ad essere (se hanno una descrizione) una lunga riga illeggibile.
• nessuna firma ecc. necessaria per l'invio del kernel.

github potrebbe semplificare la scrittura di buoni messaggi di commit e imporre il corretto "oneliner per gli shortlog e gitkla spiegazione completa per i log completi".
Ma Github no.
Al contrario, l'interfaccia di "commit on the web" di github è un unico orribile campo di immissione del testo senza un modo assolutamente sano di scrivere un messaggio di bell'aspetto.

Quando richiesto nell'area di testo per i messaggi di commit:

@torvalds L'interfaccia utente di commit di GitHub fornisce un'area di testo per i messaggi di commit.
Questo supporta nuove righe e semplifica l'esecuzione di messaggi di commit ben formattati :)

No non lo fa.
Ciò che supporta è scrivere lunghe righe che non hai idea di quanto siano lunghe.
L'area di testo non fa interruzioni di riga per te e non hai modo di giudicare dove andrebbero le interruzioni di riga.

In altre parole, rende davvero difficile fare "messaggi di commit ben formattati".
Inoltre, non impone il banale modello "oneliner per shortlog" , quindi i messaggi di commit spesso finiscono per sembrare una merda totale nei shortlog e in gitk.

Quindi l'interfaccia utente di commit di github dovrebbe avere

• finestra di testo a una riga "shortlog" separata, in modo che le persone non possano rovinare tutto.
• in qualche modo per fare effettivamente una parola a capo con il segno standard di 72 colonne.
• ricorda le firme, ecc. che alcuni progetti necessitano per motivi specifici o persino legali.