Git Metadata ตรวจสอบความสมบูรณ์?

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

• ที่ทำงานสองแห่งที่เรียกว่าxและy
• พื้นที่เก็บข้อมูลเปลือยที่เรียกว่า xy.git

ดังนั้นในตอนแรกxและyมีการผลักดันและดึงx.gitและทุกอย่างทำงานได้ดี ทีนี้สมมติว่าหนึ่งในวัตถุเมทาดาทา ( .git/objects/...) ในx.gitเสียหายด้วยเหตุผลใดก็ตาม (เลือกเหตุการณ์สุ่มที่คุณชื่นชอบ)

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

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

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

แน่นอนว่าเราสามารถแก้ไขปัญหานี้ได้ด้วยวิธีอื่น แต่ฉันก็ยังประหลาดใจ (และกังวลเล็กน้อย) ว่ามันง่ายแค่ไหนที่จะทำให้พื้นที่เก็บข้อมูลสับสนสำหรับทุกคนที่ทำงานกับมัน โดยเฉพาะอย่างยิ่งเนื่องจากข้อผิดพลาดยังคงไม่มีใครสังเกตจนกว่าจะมีคนพยายามโคลนครั้งต่อไป ไม่ควรมีการตรวจสอบสิ่งนี้ที่ใดที่หนึ่งอย่างใด?

ใครที่นี่อยากลองทำซ้ำไหม ฉันทดลองกับ git เวอร์ชั่น 2.7.4

คำแนะนำเกี่ยวกับวิธีการตรวจสอบการทุจริตดังกล่าวยินดีต้อนรับอย่างมาก

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

แต่ละวัตถุ - ไฟล์กระทำ ฯลฯ - ถูกตั้งชื่อตามแฮช SHA1 ของเนื้อหา (บวกส่วนหัวเล็ก) เมื่อใดก็ตามที่วัตถุแต่ละชิ้นถูกอ่านลงในหน่วยความจำเพื่อการใช้งานข้อมูลจะถูกแฮชและเปรียบเทียบกับชื่อของวัตถุ ไม่ตรงกันใด ๆ จะทำให้เกิดข้อผิดพลาดที่จะแสดง

อย่างไรก็ตามการดำเนินการส่วนใหญ่ไม่จำเป็นต้องอ่านที่เก็บข้อมูลทั้งหมดลงในหน่วยความจำ โดยทั่วไปคำสั่งทั้งหมดอ่านเพียงแค่ค่าต่ำสุดที่แน่นอน - แน่นอนว่าคุณจะสังเกตเห็นปัญหาหากคุณพยายามตรวจสอบการกระทำที่ผิดปกติหรือแตกต่างจากมัน แต่การดำเนินการเช่นการสร้างการกระทำไม่สนใจวัตถุก่อนหน้าใด ๆ แม้แต่ความต้องการผลักดันก็มีเพียงวัตถุเล็ก ๆ ที่เลือก (เป็นฐานของเดลต้าสำหรับแพ็ค 'thin') เพราะเพื่อนทั้งคู่รู้ว่าด้านอื่นมีอยู่แล้ว

(การเพิ่มประสิทธิภาพนี้เป็นผลลัพธ์โดยตรงของเค้าโครงตาม snapshot ตัวอย่างเช่นgit addไม่จำเป็นต้องแยกไฟล์เก่า ๆ ออกมาเพราะมันสร้าง snapshot ใหม่ตามที่ได้ทำไปแล้วgit commitเปลี่ยน snapshot นี้เป็นคอมมิท / ต้นไม้วัตถุโดยไม่ทราบอะไรเกี่ยวกับการกระทำก่อนหน้านี้ยกเว้น ID ของมัน)

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

ก่อนอื่นโปรดจำไว้ว่าคอมพิวเตอร์เครื่องเดียวกันระบบไฟล์เดียวกันจะไม่ทำการแพ็คและถ่ายโอนออบเจ็กต์มันเป็นเพียงการลิงก์ไฟล์เพื่อประหยัดพื้นที่และเวลา คุณต้องยกเลิกอย่างชัดเจนโดยการโคลนนิ่งจากfile://URL แทนที่จะเป็นเส้นทางแบบง่าย

อย่างไรก็ตามการโคลนผ่าน SSH หรือ HTTPS (หรือไฟล์ดังกล่าว: // URL) จะอ่านและเขียนข้อมูลวัตถุเพื่อสร้างแพ็คโอนดังนั้นวัตถุที่เสียหายที่ควรจะเป็นส่วนหนึ่งของการถ่ายโอนจะถูกยกเลิก กระบวนการ.

หากคุณพยายามที่จะผลักดันวัตถุที่เสียหายไปยังเซิร์ฟเวอร์ระยะไกล - ด้วยการลื่นไถลผ่านการจัดเก็บในท้องถิ่นและการเปิดออกจากระยะไกล - มันผิดปกติเล็กน้อย (โดยเฉพาะอย่างยิ่งหลังจากเรื่องราว git.kde.org 2013 ) ในรายชื่อผู้รับจดหมาย Git

(ไม่ต้องกังวลว่าเอกสารจะพูดถึงtransfer.fsckObjectsการปิดใช้งานโดยค่าเริ่มต้น - เป็นเพียงการปิดใช้งานการตรวจสอบความถูกต้องของโครงสร้างวัตถุและไวยากรณ์ไม่ใช่การตรวจสอบแฮช)

ไม่ควรมีการตรวจสอบสิ่งนี้ที่ใดที่หนึ่งอย่างใด?

การตรวจสอบเต็มรูปแบบสามารถทำได้ด้วยตนเองโดยใช้git fsckคำสั่ง เป็นความคิดที่ดีที่จะ cronjob บนที่เก็บส่วนกลางของคุณ การตรวจสอบเต็มรูปแบบนั้นไม่อัตโนมัติเนื่องจากจะใช้เวลาในการตรวจสอบพื้นที่เก็บข้อมูลที่สมบูรณ์แบบในทุกการกระทำ / push / pull / สิ่งใด ๆ สำหรับทั้งหมดยกเว้นที่เก็บ Git ที่เล็กที่สุด

การตรวจสอบบางส่วนจะเกิดขึ้นโดยปริยายเมื่อใดก็ตามที่ git ตัดสินใจที่จะเรียกใช้git gc --autoกระบวนการบำรุงรักษาพื้นหลัง การบำรุงรักษานี้จะอ่านวัตถุ 'หลวม' ที่สร้างขึ้นเมื่อเร็ว ๆ นี้ทั้งหมดและเก็บไว้ในไฟล์. pack ดังนั้นการตรวจสอบวัตถุเหล่านั้นจะทำได้ฟรี (อย่างไรก็ตามแทนที่จะวิ่งตามตารางเวลาที่ตั้งไว้มันจะทำงานเมื่อใดก็ตามที่คุณมีวัตถุหลวมมากเกินกว่าที่กำหนดไว้)