git-read-tree - ออนไลน์ในคลาวด์

โครงการ:

ชื่อ

git-read-tree - อ่านข้อมูลต้นไม้ลงในดัชนี

เรื่องย่อ

คอมไพล์ อ่านต้นไม้ [[-m [--ไม่สำคัญ] [--ก้าวร้าว] | --รีเซ็ต | --คำนำหน้า= ]
[-u [--exclude-per-directory= ] | -ผม]]
[--index-output= ] [--no-sparse-checkout]
(--ว่างเปล่า | [ [ ]])

DESCRIPTION

อ่านข้อมูลต้นไม้ที่ได้รับจาก ลงในดัชนีแต่ไม่จริง
ปรับปรุง ไฟล์ใด ๆ ที่ "แคช" (ดู: git-checkout-ดัชนี(ฮิต))

ทางเลือก มันสามารถผสานทรีเข้าในดัชนี ทำการผสานไปข้างหน้าอย่างรวดเร็ว (เช่น 2 ทาง)
หรือการผสาน 3 ทางด้วยแฟล็ก -m เมื่อใช้กับ -m แฟล็ก -u จะทำให้เกิด
อัปเดตไฟล์ในแผนผังงานด้วยผลลัพธ์ของการผสาน

การผสานเล็กน้อยทำได้โดย คอมไพล์ อ่านต้นไม้ ตัวเอง. มีแต่เส้นทางที่ขัดแย้งกันเท่านั้นที่จะอยู่ใน
สถานะไม่ได้รวมเมื่อ คอมไพล์ อ่านต้นไม้ ผลตอบแทน

OPTIONS

-m
ทำการผสาน ไม่ใช่แค่การอ่าน คำสั่งจะปฏิเสธที่จะทำงานหากไฟล์ดัชนีของคุณ
มีรายการที่ยังไม่ได้รวม แสดงว่าคุณยังไม่เสร็จสิ้นการผสานก่อนหน้านี้ของคุณ
เริ่มต้น

--รีเซ็ต
เช่นเดียวกับ -m ยกเว้นรายการที่ไม่ได้ผสานจะถูกละทิ้งแทนที่จะล้มเหลว

-u
หลังจากการผสานสำเร็จ ให้อัปเดตไฟล์ในแผนผังงานด้วยผลลัพธ์ของ
ผสาน.

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

-n, --ดรายรัน
ตรวจสอบว่าคำสั่งจะเกิดข้อผิดพลาดโดยไม่ต้องอัปเดตดัชนีหรือไฟล์ใน
ต้นไม้ทำงานจริง

-v
แสดงความคืบหน้าของการตรวจสอบไฟล์

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

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

· เมื่อด้านหนึ่งลบเส้นทางและอีกด้านหนึ่งออกจากเส้นทางที่ไม่มีการแก้ไข NS
ความละเอียดคือการลบเส้นทางนั้น

· เมื่อทั้งสองฝ่ายถอดเส้นทาง การแก้ปัญหาคือการลบเส้นทางนั้น

· เมื่อทั้งสองฝ่ายเพิ่มเส้นทางเหมือนกัน ความละเอียดคือการเพิ่มเส้นทางนั้น

--คำนำหน้า= /
เก็บเนื้อหาดัชนีปัจจุบันและอ่านเนื้อหาของ tree-ish ที่มีชื่อภายใต้
ไดเรกทอรีที่ . คำสั่งจะปฏิเสธที่จะเขียนทับรายการที่แล้ว
มีอยู่ในไฟล์ดัชนีต้นฉบับ โปรดทราบว่า / ค่าต้องลงท้ายด้วย a
เฉือน

--exclude-per-directory=
เมื่อรันคำสั่งด้วยตัวเลือก -u และ -m ผลการรวมอาจต้อง
เขียนทับเส้นทางที่ไม่ได้ติดตามในสาขาปัจจุบัน คำสั่งมักจะ
ปฏิเสธที่จะดำเนินการควบรวมกิจการเพื่อหลีกเลี่ยงการสูญเสียเส้นทางดังกล่าว อย่างไรก็ตาม ความปลอดภัยนี้
วาล์วบางครั้งได้รับในทาง เช่น มักเกิดขึ้นที่สาขาอื่น
เพิ่มไฟล์ที่เคยเป็นไฟล์ที่สร้างขึ้นในสาขาของคุณและวาล์วนิรภัย
ทริกเกอร์เมื่อคุณพยายามเปลี่ยนไปใช้แบรนช์นั้นหลังจากที่คุณรัน make แต่ก่อนรัน
ทำความสะอาดเพื่อลบไฟล์ที่สร้างขึ้น ตัวเลือกนี้บอกให้คำสั่งอ่าน
แยกไฟล์ต่อไดเรกทอรี (โดยปกติ .gitignore) และอนุญาตให้ดังกล่าว but
ไฟล์ที่ถูกละเว้นอย่างชัดเจนจะถูกเขียนทับ

--index-output=
แทนที่จะเขียนผลลัพธ์ไปที่ $GIT_INDEX_FILE ให้เขียนดัชนีผลลัพธ์เป็น
ไฟล์ที่มีชื่อ ขณะที่คำสั่งกำลังทำงาน ไฟล์ดัชนีต้นฉบับจะถูกล็อคด้วย
กลไกเหมือนเดิม ไฟล์จะต้องอนุญาตให้เป็น ตั้งชื่อใหม่(2) จาก a
ไฟล์ชั่วคราวที่สร้างขึ้นถัดจากไฟล์ดัชนีปกติ มักจะหมายถึงมัน
ต้องอยู่ในระบบไฟล์เดียวกับไฟล์ดัชนีเอง และคุณต้องเขียน
การอนุญาตไปยังไดเร็กทอรีที่มีไฟล์ดัชนีและไฟล์เอาต์พุตดัชนีอยู่

--no-sparse-เช็คเอาต์
ปิดใช้งานการสนับสนุนการเช็คเอาท์แบบกระจัดกระจายแม้ว่า core.sparseCheckout จะเป็นจริง

--ว่างเปล่า
แทนที่จะอ่านวัตถุต้นไม้ในดัชนี ให้ล้างข้อมูลนั้น


รหัสของวัตถุต้นไม้ที่จะอ่าน/ผสาน

การควบรวมกิจการ

หากระบุ -m คอมไพล์ อ่านต้นไม้ สามารถทำการผสานได้ 3 แบบ การผสานแบบต้นไม้เดียวถ้า
ให้ต้นไม้เพียง 1 ต้น, การรวมไปข้างหน้าอย่างรวดเร็วด้วยต้นไม้ 2 ต้น, หรือการรวม 3 ทางหากมี 3 ต้น
ให้.

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

นั่นหมายความว่าถ้าคุณทำ git read-tree -m ตามด้วย git checkout-index -f
-u -a, ที่ คอมไพล์ ดัชนีเช็คเอาต์ ตรวจสอบเฉพาะสิ่งที่เปลี่ยนไปจริงๆ

ใช้เพื่อหลีกเลี่ยงความผิดพลาดที่ไม่จำเป็นเมื่อ คอมไพล์ ไฟล์ต่าง ถูกเรียกใช้หลังจาก คอมไพล์
อ่านต้นไม้.

สอง ต้นไม้ ผสาน
โดยทั่วไป สิ่งนี้จะเรียกใช้เป็น git read-tree -m $H $M โดยที่ $H เป็นส่วนหัวของ
พื้นที่เก็บข้อมูลปัจจุบัน และ $M เป็นส่วนหัวของต้นไม้ต่างประเทศ ซึ่งอยู่ข้างหน้า $H
(คือเราอยู่ในสถานการณ์ที่รวดเร็ว)

เมื่อระบุต้นไม้สองต้น ผู้ใช้กำลังบอก คอมไพล์ อ่านต้นไม้ ต่อไปนี้:

1. ดัชนีปัจจุบันและแผนผังการทำงานได้มาจาก $H แต่ผู้ใช้อาจมี local
การเปลี่ยนแปลงในพวกเขาตั้งแต่ $H.

2. ผู้ใช้ต้องการกรอไปข้างหน้าเป็น $M

ในกรณีนี้ คำสั่ง git read-tree -m $H $M ทำให้แน่ใจว่าไม่มีการเปลี่ยนแปลงในเครื่องหาย
อันเป็นผลมาจาก "การรวม" นี้ นี่คือกฎ "ดำเนินการไปข้างหน้า" โดยที่ "ฉัน" หมายถึง
ดัชนี "สะอาด" หมายความว่าดัชนีและแผนผังการทำงานตรงกัน และ "มี" / "ไม่มีอะไร" หมายถึง
การมีอยู่ของเส้นทางในการคอมมิตที่ระบุ:

ผลลัพธ์ IHM
-------------------------------------------------- -----
0 ไม่มีอะไร ไม่มีอะไร ไม่มีอะไร (ไม่เกิดขึ้น)
1 ไม่มีอะไรเลย ใช้ M
2 ไม่มีอะไรอยู่ ไม่มีอะไร ลบเส้นทางออกจากดัชนี
3 ไม่มีอะไรอยู่ ใช้ M หาก "การชำระเงินเริ่มต้น"
H == M เก็บดัชนีไว้เป็นอย่างอื่น
มีอยู่ ล้มเหลว
H != ม

สะอาดฉัน==HI==M
------------------
4 ใช่ N/AN/A ไม่มีอะไร เก็บ index
5 ไม่มี N/AN/A ไม่มีอะไร เก็บ index

6 ใช่ N/A ใช่ ไม่มีอะไร เก็บ index
7 no N/A ใช่ ไม่มีอะไร เก็บ index
8 ใช่ N/A ไม่มี ไม่มีสิ่งใดล้มเหลว
9 ไม่มี ไม่มี ไม่มี ไม่มี ไม่มี ล้มเหลว

10 ใช่ ใช่ ไม่มี ไม่มี ไม่มีอะไรลบเส้นทางออกจากดัชนี
11 ไม่ใช่ ใช่ N/A อยู่ ไม่มีอะไรล้มเหลว
12 ใช่ ไม่ใช่ ไม่มี ไม่มี ไม่มีอะไรล้มเหลว
13 no no N/A มีอยู่ ไม่มีอะไรล้มเหลว

สะอาด (H==M)
------
14 ใช่ มีอยู่ เก็บ index
15 ไม่มีอยู่ เก็บ index

สะอาด I==HI==M (H!=M)
------------------
16 ใช่ ไม่มี ไม่มีอยู่จริง ล้มเหลว
17 ไม่มี ไม่มี ไม่มีอยู่จริง ล้มเหลว
18 ใช่ ไม่ใช่ ใช่ มีอยู่ เก็บดัชนี
19 no no yes มีอยู่ เก็บ index
20 ใช่ ใช่ ไม่มีอยู่ ใช้ M
21 ไม่ ใช่ ไม่มีอยู่จริง ล้มเหลว

ในทุกกรณี "เก็บดัชนี" รายการดัชนีจะคงอยู่ในไฟล์ดัชนีเดิม ถ้า
รายการไม่ทันสมัย คอมไพล์ อ่านต้นไม้ เก็บสำเนาไว้ในแผนผังการทำงานเมื่อ
ปฏิบัติการภายใต้แฟล็ก -u

เมื่อรูปแบบนี้ของ คอมไพล์ อ่านต้นไม้ กลับมาได้สำเร็จ คุณสามารถดูได้ว่า "local
การเปลี่ยนแปลง" ที่คุณทำถูกยกไปข้างหน้าโดยเรียกใช้ git diff-index --cached $M หมายเหตุ
ว่าสิ่งนี้ไม่จำเป็นต้องตรงกับสิ่งที่ git diff-index --cached $H จะเกิดขึ้น
ก่อนที่ต้นไม้สองต้นจะบรรจบกัน นี่เป็นเพราะกรณีที่ 18 และ 19 --- ถ้าคุณมีอยู่แล้ว
การเปลี่ยนแปลงใน $M (เช่น คุณอาจหยิบมันมาทางอีเมลในรูปแบบแพตช์) git diff-index
--cached $H จะบอกคุณเกี่ยวกับการเปลี่ยนแปลงก่อนการรวมนี้ แต่จะไม่แสดง
ใน git diff-index --cached $M เอาต์พุตหลังจากการผสานสองทรี

กรณีที่ 3 ค่อนข้างยุ่งยากและต้องการคำอธิบาย ผลลัพธ์จากกฎนี้อย่างมีเหตุผล
ควรจะเป็นการลบเส้นทางหากผู้ใช้จัดฉากการลบเส้นทางแล้วเปลี่ยน
สู่สาขาใหม่ อย่างไรก็ตามจะป้องกันไม่ให้การชำระเงินเริ่มต้นเกิดขึ้นดังนั้น
กฎถูกแก้ไขให้ใช้ M (แผนผังใหม่) เมื่อเนื้อหาของดัชนีว่างเปล่าเท่านั้น
มิฉะนั้น การลบพาธจะถูกเก็บไว้ตราบเท่าที่ $H และ $M เหมือนกัน

3-Way ผสาน
รายการ "ดัชนี" แต่ละรายการมีค่าสถานะ "สเตจ" สองบิต ระยะ 0 เป็นปกติ และเป็น
อันเดียวที่คุณเห็นในการใช้งานปกติทั่วไป

อย่างไรก็ตาม เมื่อคุณทำ คอมไพล์ อ่านต้นไม้ ด้วยต้นไม้สามต้น "เวที" เริ่มที่ 1

แปลว่า คุณทำได้

$ git read-tree -m

และคุณจะจบลงด้วยดัชนีที่มีทั้งหมด รายการใน "stage1" ทั้งหมด
รายการใน "stage2" และทั้งหมด รายการใน "stage2" เมื่อดำเนินการ
รวมสาขาอื่นเข้ากับสาขาปัจจุบัน เราใช้ต้นไม้บรรพบุรุษร่วมกันเป็น
, หัวหน้าสาขาปัจจุบันเป็น และหัวหน้าสาขาอื่นเป็น .

นอกจากนี้ คอมไพล์ อ่านต้นไม้ มีตรรกะกรณีพิเศษที่ระบุว่า: ถ้าคุณเห็นไฟล์ที่
ตรงกันทุกประการในสถานะต่อไปนี้ "ยุบ" กลับไปที่ "stage0":

· ระยะที่ 2 และ 3 เหมือนกัน เอาอย่างใดอย่างหนึ่ง (มันไม่แตกต่างกัน - เหมือนกัน
งานได้เสร็จสิ้นแล้วบนสาขาของเราในระยะที่ 2 และสาขาของพวกมันในระยะที่ 3)

· ระยะที่ 1 และระยะที่ 2 เหมือนกัน และระยะที่ 3 ต่างกัน ขึ้นเวทีที่ 3 (สาขาของเราใน
ระยะที่ 2 ไม่ได้ทำอะไรเลยตั้งแต่บรรพบุรุษในระยะที่ 1 ขณะที่กิ่งก้านอยู่ในระยะ
3 ทำงานกับมัน)

· ระยะที่ 1 และระยะที่ 3 เหมือนกัน และระยะที่ 2 ต่างกัน ใช้ระยะที่ 2 (เราทำ
บางอย่างในขณะที่พวกเขาไม่ได้ทำอะไรเลย)

เทศกาล คอมไพล์ เขียนต้นไม้ คำสั่งปฏิเสธที่จะเขียนต้นไม้ไร้สาระและมันจะบ่นเกี่ยวกับ
รายการที่ยังไม่ได้ผสาน หากเห็นรายการเดียวที่ไม่ใช่ระยะ 0

โอเค ทั้งหมดนี้ฟังดูเหมือนเป็นการรวบรวมกฎเกณฑ์ที่ไร้สาระ แต่จริงๆ แล้ว
สิ่งที่คุณต้องการเพื่อทำการผสานอย่างรวดเร็ว ระยะต่างๆ เป็นตัวแทนของ
"ต้นไม้ผลลัพธ์" (ขั้นที่ 0 หรือที่รู้จักว่า "ผสาน") ต้นไม้เดิม (ขั้นตอนที่ 1 หรือที่เรียกว่า "ต้นกำเนิด") และ
ต้นไม้สองต้นที่คุณพยายามจะรวมเข้าด้วยกัน (ระยะที่ 2 และ 3 ตามลำดับ)

ลำดับของขั้นตอนที่ 1, 2 และ 3 (ด้วยเหตุนี้ลำดับของสาม บรรทัดคำสั่ง
อาร์กิวเมนต์) มีความสำคัญเมื่อคุณเริ่มการรวม 3 ทางกับไฟล์ดัชนีที่มีอยู่แล้ว
มีประชากร นี่คือโครงร่างของวิธีการทำงานของอัลกอริทึม:

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

·ไฟล์ที่มี ใด ความแตกต่างของต้นไม้สามต้นจะคงอยู่คนละทิศละทาง
รายการในดัชนี อยู่ที่ "นโยบายพอร์ซเลน" ที่จะกำหนดวิธีลบ
ระยะที่ไม่ใช่ 0 และแทรกเวอร์ชันที่ผสาน

· ไฟล์ดัชนีจะบันทึกและกู้คืนด้วยข้อมูลทั้งหมดนี้ ดังนั้นคุณจึงสามารถรวมสิ่งต่างๆ ได้
เพิ่มขึ้นเรื่อยๆ แต่ตราบใดที่มีรายการในขั้นตอน 1/2/3 (เช่น "unmerged
รายการ") คุณไม่สามารถเขียนผลลัพธ์ ดังนั้นตอนนี้อัลกอริทึมการผสานจึงกลายเป็นจริง
ง่าย:

· คุณเดินดัชนีตามลำดับ และละเว้นรายการทั้งหมดของขั้นตอน 0 เนื่องจากได้
เรียบร้อยแล้ว

· หากคุณพบ "stage1" แต่ไม่มี "stage2" หรือ "stage3" ที่ตรงกัน คุณจะรู้ว่ามันเป็น
ลบออกจากต้นไม้ทั้งสอง (มีอยู่ในต้นไม้เดิมเท่านั้น) และคุณลบ
รายการนั้น

· หากคุณพบต้นไม้ "stage2" และ "stage3" ที่ตรงกัน คุณจะลบหนึ่งในนั้นและ
เปลี่ยนอีกรายการเป็นรายการ "stage0" ลบรายการ "stage1" ที่ตรงกันหากมัน
มีอยู่เช่นกัน .. กฎเล็กน้อยปกติทั้งหมด ..

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

เมื่อคุณเริ่มการรวม 3 ทางกับไฟล์ดัชนีที่มีการเติมข้อมูลแล้ว จะถือว่า
ที่แสดงถึงสถานะของไฟล์ในแผนผังงานของคุณ และคุณยังสามารถมีไฟล์ได้อีกด้วย
ด้วยการเปลี่ยนแปลงที่ไม่ได้บันทึกไว้ในไฟล์ดัชนี สันนิษฐานต่อไปว่าสถานะนี้คือ
"ได้มาจากต้นไม้ระยะที่ 2" การผสาน 3 ทางปฏิเสธที่จะทำงานหากพบรายการใน
ไฟล์ดัชนีต้นฉบับที่ไม่ตรงกับระยะที่ 2

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

$ JC=`git rev-parse --verify "HEAD^0"`
$ git ดัชนีการชำระเงิน -f -u -a $JC

คุณทำการสุ่มแก้ไขโดยไม่ต้องรัน คอมไพล์ อัพเดทดัชนี. แล้วสังเกตได้ว่าปลายของ
ต้นไม้ "ต้นน้ำ" ของคุณก้าวหน้าตั้งแต่คุณดึงจากเขา:

$ git ดึงข้อมูล git://.... linus
$ LT=`git rev-parse FETCH_HEAD`

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

$ git read-tree -m -u `git รวมฐาน $JC $LT` $JC $LT
$ git ผสานดัชนี git-merge-one-file -a
$ echo "ผสานกับไลนัส" | \
git คอมมิททรี `git write-tree` -p $JC -p $LT

สิ่งที่คุณจะกระทำคือการผสานระหว่าง $JC และ $LT อย่างหมดจดโดยที่คุณไม่ต้องดำเนินการใดๆ
การเปลี่ยนแปลง และแผนผังงานของคุณจะได้รับการอัปเดตเป็นผลของการผสาน

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

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

กระจัดกระจาย ชำระเงิน

"การชำระเงินแบบกระจัดกระจาย" อนุญาตให้เติมไดเรกทอรีการทำงานแบบกระจัดกระจาย มันใช้
ข้ามเวิร์กทรีบิต (ดู git-update-ดัชนี(1)) เพื่อบอก Git ว่าเป็นไฟล์ในการทำงานหรือไม่
ไดเรกทอรีเป็นสิ่งที่ควรค่าแก่การดู

คอมไพล์ อ่านต้นไม้ และคำสั่งแบบรวมอื่นๆ (คอมไพล์ ผสาน, คอมไพล์ เช็คเอาต์...) สามารถช่วย
รักษาบิตแมปข้ามเวิร์กทรีและการอัพเดตไดเร็กทอรีการทำงาน
$GIT_DIR/info/sparse-checkout ใช้เพื่อกำหนดบิตแมปอ้างอิงข้ามเวิร์กทรี เมื่อไหร่
คอมไพล์ อ่านต้นไม้ จำเป็นต้องอัปเดตไดเร็กทอรีการทำงาน โดยจะรีเซ็ตบิตข้ามเวิร์กทรีเป็น
ดัชนีตามไฟล์นี้ ซึ่งใช้รูปแบบเดียวกับไฟล์ .gitignore ถ้าเข้า
ตรงกับรูปแบบในไฟล์นี้ skip-worktree จะไม่ถูกตั้งค่าในรายการนั้น มิฉะนั้น,
ข้ามเวิร์กทรีจะถูกตั้งค่า

จากนั้นจะเปรียบเทียบค่าข้ามเวิร์กทรีใหม่กับค่าก่อนหน้า หากข้ามเวิร์กทรีเปลี่ยน
จากการตั้งค่าเป็น unset จะเพิ่มไฟล์ที่เกี่ยวข้องกลับ หากเปลี่ยนจาก unset เป็น set
ไฟล์นั้นจะถูกลบออก

แม้ว่าโดยปกติแล้ว $GIT_DIR/info/sparse-checkout จะใช้เพื่อระบุไฟล์ที่อยู่ในนั้น คุณสามารถ
ยังระบุด้วยว่าไฟล์อะไร ไม่ ใน โดยใช้รูปแบบลบล้าง ตัวอย่างเช่น การลบไฟล์
ไม่ต้องการ:

/*
! ไม่ต้องการ

อีกสิ่งที่ยุ่งยากคือการเติมข้อมูลไดเร็กทอรีการทำงานใหม่ทั้งหมดเมื่อคุณไม่ต้องการอีกต่อไป
ชำระเงินเบาบาง คุณไม่สามารถปิดการใช้งาน "sparse checkout" ได้เพราะว่า skip-worktree bits เป็น
ยังอยู่ในดัชนีและไดเร็กทอรีการทำงานของคุณยังคงมีการกระจัดกระจายอยู่ คุณควร
เติมไดเรกทอรีการทำงานใหม่ด้วยเนื้อหาไฟล์ $GIT_DIR/info/sparse-checkout เป็น
ดังต่อไปนี้:

/*

จากนั้นคุณสามารถปิดใช้งานการชำระเงินแบบกระจัดกระจาย รองรับการชำระเงินแบบเบาบางใน คอมไพล์ อ่านต้นไม้ และที่คล้ายกัน
คำสั่งถูกปิดใช้งานโดยค่าเริ่มต้น คุณต้องเปิด core.sparseCheckout เพื่อให้มี
การสนับสนุนการชำระเงินที่กระจัดกระจาย

ใช้ git-read-tree ออนไลน์โดยใช้บริการ onworks.net