일부 오픈 소스 프로젝트가 풀 요청을 수락하지 않지만 패치 파일 만 전자 메일로 보내는 이유는 무엇입니까?

일부 오픈 소스 프로젝트가 풀 요청을 수락하지 않지만 전자 메일 패치 파일 만 기고자가 필요한 이유는 무엇입니까? 예를 들어 Git은 github 또는 다른 분산 scm 호스팅에 코드를 게시하지만. 패치 파일을 전송하는 것은 대화식이거나 편리하지 않습니다. 패치 파일은 구식입니다. 풀 요청은 대화식입니다. 다른 사람들도 토론 할 수 있습니다.

풀 요청을 담당 할 담당자에 따라 달라질 수 있습니다.

이 경우 리누스 토발즈 (Linus Torvalds) , 음 ... 좋은 오래된 패치 바람직하다 :

github pull 요청을하지 않습니다.

github은 나에게 뽑아달라고 요청하는 사람에게 유효한 이메일 주소조차도 모든 관련 정보를 버립니다 .
diffstat는 또한 부족하고 쓸모가 없습니다.

Git에는 멋진 pull-request 생성 모듈이 제공되지만 github은 대신 자체적으로 열등한 버전으로 교체하기로 결정했습니다.
결과적으로, 나는 이런 종류의 것들에 github을 쓸모없는 것으로 생각합니다.

그것은 괜찮다 호스팅 ,하지만 온라인 풀 요청과는 순수한 쓰레기를 편집 커밋합니다.
나는 github 사람들에게 내 걱정에 대해 이야기했지만 그들이 중요하다고 생각하지 않았기 때문에 포기했다. github에 버그 리포트를 작성하십시오.

그는 세부 사항 :

위해서는 나 GitHub의에서 풀하려면 다음을 수행해야합니다

• (a) 풀을 요청할 때 github이 수행하는 두뇌 손상 크랩이 아닌 실제 풀 요청을하십시오.
  • 실제 설명 ,
  • 적절한 이메일 주소 ,
  • 적절한 shortlog 및
  • 적절한 diffstat .
• (b) github ID는 임의적이므로 풀 요청이 서명 된 태그 일 것으로 예상 되므로 문제가되는 사람의 ID를 확인할 수 있습니다.

또한 github 웹 인터페이스로 이루어진 커밋을 풀기를 거부합니다.
다시 말하지만, 그 이유는 github 웹 인터페이스가 작동하는 방식에서 커밋은 항상 순수 쓰레기이기 때문입니다.
GitHub의에서 수행 커밋은 변함없이 github에 만들고 커밋 때문에 일을하지 않는, 완전히 읽을 수 설명이 있는 A가 커밋 메시지에서 커널 사람들이 기대하는 간단한 일들을 :

• "첫 번째 줄에 짧은 한 줄 설명"
• 당신이 입력하는 긴 설명의 확실한 단어 감싸기 없음 : github commit 메시지는 (읽기가 전혀 없다면) 읽을 수없는 긴 줄입니다.
• 커널 제출에 필요한 사인 오프 등이 없습니다.

github 은 좋은 커밋 메시지를 작성하고 적절한 "단기 로그를위한 oneliner 및 gitk전체 로그를위한 전체 설명 "을 쉽게 적용 할 수 있도록합니다 .
그러나 github는 그렇지 않습니다.
대신, github "commit on the web"인터페이스는 멋진 메시지를 작성할 수있는 확실한 방법이없는 하나의 끔찍한 텍스트 입력 필드입니다.

커밋 메시지를위한 텍스트 영역에 도전 할 때 :

@torvalds GitHub 커밋 UI는 커밋 메시지를위한 텍스트 영역을 제공합니다.
이것은 새로운 줄을 지원하고 멋진 형식의 커밋 메시지를 쉽게 수행 할 수있게합니다 :)

아닙니다.
그것이 지원하는 것은 당신이 얼마나 오래 단서를 찾지 않은 긴 줄을 쓰는 것입니다.
텍스트 영역은 줄 바꿈을하지 않으며 줄 바꿈의 위치를 ​​판단 할 방법이 없습니다.

다시 말해, "멋지게 형식화 된 커밋 메시지"를하기가 매우 어렵습니다.
또한 간단한 "oneliner for shortlog"모델을 적용하지 않기 때문에 커밋 메시지는 종종 shortlogs와 gitk에서 전체 쓰레기처럼 보입니다.

따라서 github commit UI는

• "단축"한 줄짜리 텍스트 창을 분리하여 사람들이 망칠 수 없도록합니다.
• 실제로 표준 72 열 표시에서 제자리를 자동으로 감쌀 수있는 방법입니다.
• 일부 프로젝트에는 프로젝트 별 또는 법적 이유가 필요하다는 사인 오프 알림에 대한 알림.