เหตุใดโครงการโอเพนซอร์สบางโครงการไม่รับคำขอดึง แต่ส่งอีเมลไฟล์ปะแก้เท่านั้น

เหตุใดโครงการโอเพนซอร์สบางโครงการจึงไม่ยอมรับคำขอดึง แต่ต้องการผู้ร่วมให้ข้อมูลไฟล์แพตช์อีเมลเท่านั้น เช่น Git แม้ว่าพวกเขาจะเผยแพร่โค้ดใน github หรือ scm โฮสติ้งแบบกระจายอื่น ๆ ไม่สะดวกหรือไม่สามารถส่งไฟล์ปะแก้ได้ ไฟล์ Patch เป็นวิธีที่ล้าสมัย คำขอดึงนั้นเป็นแบบโต้ตอบ คนอื่นอาจพูดคุยกัน

ขึ้นอยู่กับว่าใครจะรับผิดชอบในการยอมรับคำขอดึงของคุณ

ถ้าเป็นLinus Torvaldsก็ดี ... แพทช์เก่าดีกว่า :

ฉันไม่ขอ github ดึง

GitHub พ่นออกข้อมูลที่เกี่ยวข้องทั้งหมดเช่นมีแม้กระทั่งที่อยู่อีเมลที่ถูกต้องสำหรับคนที่ขอให้ฉันดึง
ดิฟสแตทยังขาดและไร้ประโยชน์

Git มาพร้อมกับโมดูลสร้างคำขอดึงที่ดี แต่ GitHub ตัดสินใจแทนที่ด้วยรุ่นที่ด้อยกว่าโดยสิ้นเชิง
เป็นผลให้ฉันพิจารณา gitHub ไร้ประโยชน์สำหรับสิ่งเหล่านี้

ไม่เป็นไรสำหรับโฮสติ้งแต่คำขอดึงและการแก้ไขคอมมิชชันออนไลน์เป็นเพียงขยะที่แท้จริง
ฉันบอกคนอื่นเกี่ยวกับความกังวลของฉันพวกเขาไม่คิดว่าพวกเขามีความสำคัญดังนั้นฉันจึงยอมแพ้ อย่าลังเลที่จะทำการรายงานข้อผิดพลาดกับ GitHub

เขามีรายละเอียด:

เพื่อให้ฉันสามารถดึงจาก GitHub คุณต้อง:

• (a) สร้างคำขอการดึงที่แท้จริงไม่ใช่อึสมองที่เสียหายที่ GitHub ทำเมื่อคุณขอให้ทำการดึง:
  • คำอธิบายจริง ,
  • ที่อยู่อีเมลที่ถูกต้อง ,
  • shortlog ที่เหมาะสมและ
  • diffstat เหมาะสม
• (b) เนื่องจากตัวตน Github เป็นแบบสุ่มฉันคาดว่าคำขอดึงจะเป็นแท็กที่ลงนามเพื่อให้ฉันสามารถยืนยันตัวตนของบุคคลที่เป็นปัญหาได้

ฉันยังปฏิเสธที่จะดึงคำมั่นสัญญาที่ทำกับเว็บอินเตอร์เฟส Github
อีกครั้งเหตุผลก็คือวิธีที่เว็บอินเทอร์เฟซ github ทำงานได้อย่างที่ไม่เคยทำมาก่อน
commits ทำบน GitHub คงเส้นคงวามีคำอธิบายไม่สามารถอ่านได้โดยสิ้นเชิงเพราะ GitHub กระทำการทำสิ่งที่ไม่ได้ทำใด ๆของสิ่งที่ง่ายที่สุดที่คนเคอร์เนลคาดหวังจากการกระทำข้อความ:

• ไม่มี "คำอธิบายสั้น ๆ หนึ่งบรรทัดในบรรทัดแรก"
• ไม่มีการตัดคำที่มีเหตุผลของคำอธิบายแบบยาวที่คุณพิมพ์: github ส่งข้อความมีแนวโน้มที่จะ (ถ้าพวกเขามีคำอธิบายใด ๆ เลย) หนึ่งบรรทัดที่อ่านไม่ได้
• ไม่มีการลงชื่อออก ฯลฯ ที่เราต้องการสำหรับการส่งเคอร์เนล

Github สามารถทำให้ง่ายต่อการเขียนข้อความที่เหมาะสมและบังคับใช้ "oneliner สำหรับ shortlogs และgitkคำอธิบายแบบเต็มสำหรับบันทึกแบบเต็ม"
แต่ GitHub ไม่ได้
แต่อินเทอร์เฟซ GitHub "ส่งบนเว็บ" เป็นช่องป้อนข้อความที่น่ากลัวเพียงช่องเดียวที่ไม่มีวิธีการเขียนข้อความที่ดูดี

เมื่อถูกท้าทายในพื้นที่ข้อความเพื่อยอมรับข้อความ:

@torvalds GitHub ส่ง UI ให้พื้นที่ข้อความสำหรับส่งข้อความ
สิ่งนี้รองรับบรรทัดใหม่และทำให้ง่ายต่อการจัดรูปแบบข้อความยอมรับ :)

ไม่มันไม่
สิ่งที่รองรับคือการเขียนเส้นยาว ๆ ที่คุณยังไม่ได้รู้ว่านานแค่ไหน
พื้นที่ข้อความไม่ได้ขึ้นบรรทัดใหม่ให้คุณและคุณไม่มีทางที่จะตัดสินว่าตัวแบ่งบรรทัดจะเป็นอย่างไร

กล่าวอีกอย่างหนึ่งก็คือมันยากมากที่จะทำ
นอกจากนี้ยังไม่บังคับใช้จิ๊บจ๊อย "oneliner สำหรับ shortlog" รูปแบบดังนั้นข้อความกระทำมักจะจบลงมองเหมือนอึรวมใน shortlogs และ gitk

ดังนั้น GitHub ที่ทำ UI ควรมี

• แยก "shortlog" หน้าต่างข้อความแบบหนึ่งซับเพื่อให้ผู้ใช้ไม่สามารถขันมันได้
• วิธีการตัดคำที่มีเหตุผลบางอย่างที่เครื่องหมาย 72 คอลัมน์มาตรฐาน
• การแจ้งเตือนเกี่ยวกับการลงชื่อออก ฯลฯ ซึ่งบางโครงการต้องการเหตุผลเฉพาะของโครงการหรือแม้แต่กฎหมาย