Por que alguns projetos de código aberto não aceitam solicitações pull, mas enviam apenas arquivos de patch por e-mail

Por que alguns projetos de código aberto não aceitam solicitações pull, mas exigem que os colaboradores enviem apenas arquivos de correção por email? por exemplo, Git Embora eles publiquem código no github ou em outra hospedagem distribuída de scm. Não é interativo nem conveniente enviar arquivos de correção. O arquivo de correção é uma maneira antiquada. As solicitações pull são interativas. Outras pessoas também podem discutir.

Depende de quem será o responsável por aceitar sua solicitação de recebimento.

Se for Linus Torvalds , bem ... um bom e velho patch é preferível :

Eu não faço solicitações pull do github.

O github joga fora todas as informações relevantes, como ter até um endereço de e-mail válido para a pessoa que está me pedindo .
O diffstat também é deficiente e inútil.

O Git vem com um bom módulo de geração de solicitação por solicitação, mas o github decidiu substituí-lo por uma versão totalmente inferior.
Como resultado, considero o github inútil para esse tipo de coisa.

É bom para hospedagem , mas as solicitações de recebimento e a edição de confirmação on-line são apenas lixo.
Eu contei às pessoas do github sobre minhas preocupações, elas não achavam que eram importantes, então eu desisti. Sinta-se livre para fazer um relatório de erros no github.

Ele detalha:

Para que eu possa usar o github, você precisa:

• (a) faça uma solicitação de recebimento real, não a porcaria que o github faz quando você solicita uma solicitação:
  • explicação real ,
  • endereços de e-mail adequados ,
  • atalho adequado e
  • diffstat adequado .
• (b) como as identidades do github são aleatórias, espero que a solicitação de recebimento seja uma tag assinada , para que eu possa verificar a identidade da pessoa em questão.

Também me recuso a receber confirmações feitas com a interface da web do github.
Novamente, a razão disso é que, da maneira como a interface da web do github funciona, esses commit são invariavelmente pura porcaria.
As confirmações feitas no github invariavelmente têm descrições totalmente ilegíveis, porque a tarefa de criação de commit do github não faz nenhuma das coisas mais simples que o pessoal do kernel espera de uma mensagem de commit:

• nenhuma "descrição curta de uma linha na primeira linha"
• nenhuma quebra de linha sadia da descrição longa digitada: as mensagens de confirmação do github tendem a ser (se houver alguma descrição) uma longa linha ilegível.
• sem aprovações etc. que exigimos para envios de kernel.

O github pode facilitar a escrita de boas mensagens de confirmação e aplicar o "oneliner apropriado para shortlogs e gitkuma explicação completa para logs completos".
Mas o github não.
Em vez disso, a interface "commit on the web" do github é um único campo de entrada de texto horrível, com absolutamente nenhuma maneira sensata de escrever uma mensagem bonita.

Quando desafiado na área de texto para mensagens de confirmação:

@torvalds A interface do usuário de confirmação do GitHub fornece uma área de texto para as mensagens de confirmação.
Isso suporta novas linhas e facilita a criação de mensagens de confirmação bem formatadas :)

Não, não faz.
O que ele suporta é escrever linhas longas que você não tem idéia de quanto tempo elas têm.
A área de texto não faz quebras de linha para você e você não tem como julgar para onde iriam as quebras de linha.

Em outras palavras, torna muito difícil executar "mensagens de confirmação bem formatadas".
Ele também não aplica o modelo trivial "oneliner for shortlog" ; portanto, as mensagens de confirmação geralmente acabam parecendo uma porcaria total nos shortlogs e no gitk.

Portanto, a interface do usuário de confirmação do github deve ter

• separar a janela de texto de uma linha "shortlog", para que as pessoas não possam estragar tudo.
• alguma maneira de realmente fazer uma quebra de linha sã na marca padrão de 72 colunas.
• lembretes sobre aprovações etc, que alguns projetos precisam por motivos específicos ou mesmo legais.