Чому деякі проекти з відкритим кодом не приймають запити на виклики, а надсилають лише патчі з патчами

Чому деякі проекти з відкритим кодом не приймають запити на виклик, але вимагають від співробітників надсилати лише патчі-файли електронної пошти? наприклад, Git Хоча вони публікують код у github або іншому розповсюдженому хостингу scm. Надіслати файли патчів не інтерактивно, ані зручно. Патч-файл - це старомодний спосіб. Запити на виклик є інтерактивними. Інші люди також можуть обговорити.

Це може залежати від того, хто буде відповідальним за прийняття Вашого запиту на притягнення.

Якщо це Лінус Торвальдс , ну ... краще старий патч :

Я не роблю запитів на тягнення до Github.

github викидає всю релевантну інформацію, наприклад, маючи навіть дійсну адресу електронної пошти для людини, яка просить мене зняти .
Дифстат також є дефіцитним і марним.

Git оснащений чудовим модулем покоління запитів, але github замість цього вирішив замінити його на власну абсолютно неповноцінну версію.
Як результат, я вважаю Github марним для подібних речей.

Для хостингу це чудово , але запити на виклики та редагування в Інтернеті здійснюють лише чисто сміття.
Я розповідав людям github про свої турботи, вони не думали, що вони мають значення, тому я здався. Не соромтеся робити бугрепорт до github.

Він детально:

Для того, щоб я витягнув з github, вам потрібно:

• (а) зробіть справжній запит на витягування, а не пошкоджене лайно, яке робить Github, коли ви попросите його просити тягнути:
  • реальне пояснення ,
  • належні адреси електронної пошти ,
  • належний короткий журнал та
  • належний дифстат .
• (b) оскільки ідентичності github є випадковими, я очікую, що запит на притягнення буде підписаним тегом , щоб я міг перевірити особу відповідної особи.

Я також відмовляюся брати коміти, зроблені за допомогою веб-інтерфейсу github.
Знову ж таки, причина цього полягає в тому, що те, як працює веб-інтерфейс github, ці коміти незмінно є чистою лайною.
Коміти, виконані на github, незмінно мають абсолютно нечитабельні описи, оскільки створення файлу github не робить жодної з найпростіших речей, яких очікують люди з ядра від повідомлення про виконання:

• немає "короткого однорядкового опису в першому рядку"
• жодне здорове обговорення слів із довгого опису, який ви вводите: повідомлення github фіксують, як правило, (якщо вони взагалі мають будь-який опис) одним довгим нечитабельним рядком.
• жодних підписок тощо, необхідних для подання ядра.

github може полегшити написання гарних повідомлень про фіксацію та застосувати належний "oneliner для коротких журналів та gitkповне пояснення для повних журналів".
Але github ні.
Натомість інтерфейс github "виконувати в Інтернеті" - це одне єдине жахливе поле для введення тексту з абсолютно відсутнім розумним способом написання гарного повідомлення.

У разі виклику в текстовій області для повідомлень про фіксацію

@torvalds Інтерфейс користувача GitHub надає текстову область для повідомлень про фіксацію.
Це підтримує нові рядки і дозволяє легко робити добре відформатовані повідомлення про фіксацію :)

Ні, це не так.
Те, що він підтримує, - це писати довгі рядки, про які ви не розумієте, як довго вони знаходяться.
Текстова область не робить для вас розривів рядків, і у вас немає способу судити, куди піде розрив рядків.

Іншими словами, це робить дуже важко дійсно робити "добре відформатовані повідомлення про здійснення".
Він також не застосовує тривіальну модель "oneliner for shortlog" , тому повідомлення комітів часто виявляються схожими на загальне лайно в шорт-журналах та в gitk.

Отже, UI github commit повинен мати

• окреме текстове вікно з коротким блоком, щоб люди не змогли це зробити.
• якимось чином реально виконати розгорнуту обробку слів у стандартній позначці 72-стовпчика.
• нагадування про реєстрацію тощо, які потрібні деяким проектам з конкретних проектів або навіть юридичних причин.