Perché alcuni progetti open source non accettano richieste di pull, ma richiedono che i contributori inviino solo ai file di patch e-mail? per esempio. Idiota Sebbene pubblichino codice in github o altro hosting scm distribuito. Non è interattivo né comodo inviare file di patch. Il file di patch è obsoleto. Le richieste di pull sono interattive. Altre persone possono anche discutere.
Può dipendere da chi sarà responsabile dell'accettazione della richiesta di pull.
Se è Linus Torvalds , beh ... a è preferibile una buona vecchia patch :
I don't do github pull requests.
github throws away all the relevant information, like having even a valid email address for the person asking me to pull.
The diffstat is also deficient and useless.Git comes with a nice pull-request generation module, but github instead decided to replace it with their own totally inferior version.
As a result, I consider github useless for these kinds of things.It's fine for hosting, but the pull requests and the online commit editing, are just pure garbage.
I've told github people about my concerns, they didn't think they mattered, so I gave up. Feel free to make a bugreport to github.
Dettagli:
In order for me to pull from github, you need to:
- (a) make a real pull request, not the braindamaged crap that github does when you ask it to request a pull:
- real explanation,
- proper email addresses,
- proper shortlog, and
- proper diffstat.
- (b) since github identities are random, I expect the pull request to be a signed tag, so that I can verify the identity of the person in question.
I also refuse to pull commits that have been made with the github web interface.
Again, the reason for that is that the way the github web interface work, those commits are invariably pure crap.
Commits done on github invariably have totally unreadable descriptions, because the github commit making thing doesn't do any of the simplest things that the kernel people expect from a commit message:
- no "short one-line description in the first line"
- no sane word-wrap of the long description you type: github commit messages tend to be (if they have any description at all) one long unreadable line.
- no sign-offs etc that we require for kernel submissions.
github could make it easy to write good commit messages and enforce the proper "oneliner for shortlogs and
gitk, full explanation for full logs".
But github doesn't.
Instead, the github "commit on the web" interface is one single horrible text-entry field with absolutely no sane way to write a good-looking message.
In caso di problemi nell'area di testo per i messaggi di commit:
@torvalds The GitHub commit UI provides a text area for commit messages.
This supports new lines and makes it easy to do nicely formatted commit messages :)No, non lo è.
Quello che supporta è scrivere le linee lunghe che non hai un indizio per quanto tempo sono.
L'area di testo non fa le interruzioni di linea per te e non hai modo di giudicare dove sarebbero andate le interruzioni di riga.In altre parole, rende davvero difficile fare "messaggi di commit ben formattati".
Inoltre non impone il banale "oneliner per il" modello di shortlog ", quindi i messaggi di commit spesso finiscono per sembrare una schifezza totale in shortlogs e in gitk.Quindi l'interfaccia utente di Github deve avere
- separa la finestra di testo "shortlog" con un solo liner, in modo che le persone non possano rovinare tutto.
- un modo per fare effettivamente un buon word-wrap al marchio standard di 72 colonne.
- promemoria sui blocchi di iscrizione ecc. che alcuni progetti necessitano di motivi specifici del progetto o anche legali.
Leggi altre domande sui tag open-source version-control