git gc --aggressive vs git repack

ฉันกำลังมองหาวิธีลดขนาดของที่gitเก็บ การค้นหาทำให้ฉันgit gc --aggressiveเกือบตลอดเวลา ฉันยังได้อ่านว่านี่ไม่ใช่แนวทางที่ต้องการ

ทำไม? ฉันควรระวังgc --aggressiveอะไรบ้างหากกำลังวิ่ง

git repack -a -d --depth=250 --window=250gc --aggressiveขอแนะนำมากกว่า ทำไม? วิธีการที่ไม่repackลดขนาดของพื้นที่เก็บข้อมูลได้หรือไม่ นอกจากนี้ฉันยังไม่ค่อยชัดเจนเกี่ยวกับธง--depthและ--window.

ฉันควรเลือกอะไรระหว่างgcกับrepack? ฉันควรใช้เมื่อใดgcและrepack?

ปัจจุบันไม่มีความแตกต่าง: git gc --aggressiveดำเนินการตามข้อเสนอแนะของ Linus ที่ทำในปี 2550; ดูด้านล่าง สำหรับเวอร์ชัน 2.11 (ไตรมาสที่ 4 ปี 2016) ค่าเริ่มต้นของคอมไพล์คือความลึก 50 หน้าต่างขนาด 250 เป็นสิ่งที่ดีเพราะจะสแกนส่วนที่ใหญ่กว่าของแต่ละวัตถุ แต่ความลึกที่ 250 นั้นไม่ดีเนื่องจากทำให้ห่วงโซ่ทุกชิ้นอ้างถึงความเก่าที่ลึกมาก วัตถุซึ่งทำให้การทำงานของคอมไพล์ในอนาคตทั้งหมดช้าลงสำหรับการใช้งานดิสก์ที่ลดลงเล็กน้อย

ประวัติความเป็นมา

Linus แนะนำ (ดูด้านล่างสำหรับโพสต์รายชื่ออีเมลฉบับเต็ม) โดยใช้git gc --aggressiveเฉพาะเมื่อคุณมีในคำพูดของเขา " แพ็คที่ไม่ดีจริงๆ " หรือ "เดลต้าที่แย่มากจริงๆ" อย่างไรก็ตาม "เกือบตลอดเวลาในกรณีอื่น ๆ มันแย่จริงๆ สิ่งที่ต้องทำ." ผลลัพธ์อาจทำให้ที่เก็บของคุณอยู่ในสภาพที่แย่กว่าตอนที่คุณเริ่ม!

คำสั่งที่เขาแนะนำให้ทำอย่างถูกต้องหลังจากที่นำเข้า "ประวัติศาสตร์อันยาวนานและเกี่ยวข้อง" คือ

git repack -a -d -f --depth=250 --window=250

แต่ตอนนี้ถือว่าคุณมีอยู่แล้วเอาออก gunk ที่ไม่พึงประสงค์จากประวัติศาสตร์พื้นที่เก็บข้อมูลของคุณและที่คุณได้ทำตามรายการตรวจสอบสำหรับการหดตัวที่พบพื้นที่เก็บข้อมูลในเอกสารgit filter-branch

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

• คุณได้ลบชื่อไฟล์รูปแบบต่างๆออกไปแล้วจริงๆถ้าหยดถูกย้ายไปตลอดอายุการใช้งาน git log --name-only --follow --all -- filenameสามารถช่วยคุณค้นหาการเปลี่ยนชื่อ

• จริงๆคุณกรอง refs ทั้งหมด: ใช้เมื่อเรียก--tag-name-filter cat -- --allgit filter-branch

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

• โคลนด้วยgit clone file:///path/to/repo. โคลนจะไม่มีวัตถุที่ถูกลบออก ดู git-clone (โปรดทราบว่าการโคลนนิ่งด้วยเส้นทางธรรมดาเพียงแค่เชื่อมโยงทุกอย่าง!)

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

• ลบการอ้างอิงเดิมที่สำรองไว้โดย git-filter-branch: say

  git for-each-ref --format="%(refname)" refs/original/ |
    xargs -n 1 git update-ref -d
  

• หมดอายุ reflogs ทั้งหมดด้วยgit reflog expire --expire=now --all.

• Garbage รวบรวมอ็อบเจ็กต์ที่ไม่ได้อ้างอิงทั้งหมดด้วยgit gc --prune=now(หรือหากคุณgit gcยังใหม่ไม่เพียงพอที่จะรองรับอาร์กิวเมนต์ให้--pruneใช้git repack -ad; git pruneแทน)

Date: Wed, 5 Dec 2007 22:09:12 -0800 (PST)
From: Linus Torvalds <torvalds at linux-foundation dot org>
To: Daniel Berlin <dberlin at dberlin dot org>
cc: David Miller <davem at davemloft dot net>,
    ismail at pardus dot org dot tr,
    gcc at gcc dot gnu dot org,
    git at vger dot kernel dot org
Subject: Re: Git and GCC
In-Reply-To: <4aca3dc20712052111o730f6fb6h7a329ee811a70f28@mail.gmail.com>
Message-ID: <alpine.LFD.0.9999.0712052132450.13796@woody.linux-foundation.org>
References: <4aca3dc20712051947t5fbbb383ua1727c652eb25d7e@mail.gmail.com>
            <20071205.202047.58135920.davem@davemloft.net>
            <4aca3dc20712052032n521c344cla07a5df1f2c26cb8@mail.gmail.com>
            <20071205.204848.227521641.davem@davemloft.net>
            <4aca3dc20712052111o730f6fb6h7a329ee811a70f28@mail.gmail.com>

ในวันพฤหัสบดีที่ 6 ธันวาคม 2550 Daniel Berlin เขียนว่า:

อันที่จริงปรากฎว่าgit-gc --aggressiveบางครั้งสิ่งที่โง่เขลาในการแพ็คไฟล์ไม่ว่าคุณจะแปลงจาก SVN repo หรือไม่ก็ตาม

อย่างแน่นอน git --aggressiveส่วนใหญ่เป็นใบ้ มันมีประโยชน์จริงๆสำหรับกรณี "ฉันรู้ว่าฉันมีแพ็คที่ไม่ดีจริงๆและฉันอยากจะทิ้งการตัดสินใจบรรจุหีบห่อที่ไม่ดีทั้งหมดที่ฉันเคยทำไป"

เพื่ออธิบายสิ่งนี้มันคุ้มค่าที่จะอธิบาย (คุณอาจจะรู้อยู่แล้ว แต่ขอให้ฉันอ่านพื้นฐานต่อไป) การทำงานของ git delta-chains และมันแตกต่างจากระบบอื่น ๆ อย่างไร

ใน SCM อื่น ๆ โดยทั่วไปแล้วเดลต้าเชนจะได้รับการแก้ไข อาจเป็น "ไปข้างหน้า" หรือ "ถอยหลัง" และอาจมีการพัฒนาขึ้นเล็กน้อยเมื่อคุณทำงานกับที่เก็บ แต่โดยทั่วไปแล้วจะเป็นห่วงโซ่การเปลี่ยนแปลงของไฟล์เดียวที่แสดงเป็นเอนทิตี SCM เดี่ยวบางประเภท ใน CVS เห็นได้ชัดว่าเป็น*,vไฟล์และระบบอื่น ๆ อีกมากมายทำสิ่งที่คล้ายกัน

Git ยังทำเดลต้าเชน แต่มันทำแบบ "หลวม ๆ " มากกว่า ไม่มีนิติบุคคลตายตัว Deltas ถูกสร้างขึ้นจากเวอร์ชันสุ่มอื่น ๆ ที่ git ถือว่าเป็นตัวเลือกเดลต้าที่ดี (ด้วยการวิเคราะห์พฤติกรรมที่ประสบความสำเร็จอย่างมาก) และไม่มีกฎการจัดกลุ่มที่ยากอย่างแน่นอน

นี่เป็นสิ่งที่ดีมาก เป็นสิ่งที่ดีสำหรับเหตุผลเชิงแนวคิดต่างๆ ( กล่าวคือคอมไพล์ภายในไม่จำเป็นต้องสนใจห่วงโซ่การแก้ไขทั้งหมด - มันไม่ได้คิดในแง่ของเดลต้าเลย) แต่ก็ยอดเยี่ยมเช่นกันเพราะการกำจัดกฎเดลต้าที่ไม่ยืดหยุ่นหมายความว่า คอมไพล์นั้นไม่มีปัญหาใด ๆ เลยในการรวมไฟล์สองไฟล์เข้าด้วยกันตัวอย่างเช่นไม่มี*,v"ไฟล์แก้ไข" ตามอำเภอใจที่มีความหมายซ่อนอยู่

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

และนี่คือที่--aggressiveมาของชื่อที่ไม่ดีจริงๆในขณะที่ git โดยทั่วไปจะพยายามใช้ข้อมูลเดลต้าซ้ำ (เพราะเป็นความคิดที่ดีและไม่ต้องเสียเวลา CPU ในการค้นหาเดลต้าที่ดีทั้งหมดที่เราพบก่อนหน้านี้อีกครั้ง) บางครั้งคุณ ต้องการบอกว่า“ มาเริ่มกันใหม่โดยใช้กระดานชนวนว่างเปล่าและเพิกเฉยต่อข้อมูลเดลต้าก่อนหน้าทั้งหมดและพยายามสร้างเดลต้าชุดใหม่”

ดังนั้นจึง--aggressiveไม่ได้เกี่ยวกับการก้าวร้าว แต่เป็นการเสียเวลาของ CPU ในการตัดสินใจใหม่ที่เราได้ทำไปแล้วก่อนหน้านี้!

บางครั้งนั่นก็เป็นเรื่องดี โดยเฉพาะอย่างยิ่งเครื่องมือนำเข้าบางอย่างสามารถสร้างเดลต้าที่เลวร้ายได้อย่างน่าสยดสยอง git fast-importตัวอย่างเช่นสิ่งที่ใช้มักจะไม่มีเค้าโครงเดลต้าที่ยอดเยี่ยมมากนักดังนั้นจึงควรพูดว่า "ฉันต้องการเริ่มจากกระดานชนวนที่สะอาด"

แต่เกือบตลอดเวลาในกรณีอื่น ๆ มันเป็นสิ่งที่เลวร้ายจริงๆ มันจะเสียเวลา CPU และโดยเฉพาะอย่างยิ่งถ้าคุณทำงานได้ดีในการเดลต้าก่อนหน้านี้ผลลัพธ์สุดท้ายจะไม่นำเดลต้าที่ดีทั้งหมดที่คุณพบมาใช้ซ้ำดังนั้นคุณจะจบลงด้วย ผลสุดท้ายแย่ลงด้วย!

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

โดยทั่วไปการทำที่เพิ่มขึ้นเป็นวิธีการที่เหมาะสมและดีกว่าทำgit gc git gc --aggressiveมันจะนำเดลตาเก่ามาใช้ใหม่และเมื่อไม่พบเดลตาเก่าเหล่านั้น (เหตุผลในการทำ GC แบบเพิ่มหน่วยตั้งแต่แรก!) มันจะสร้างอันใหม่

ในทางกลับกันมันเป็นความจริงอย่างแน่นอนที่“ การนำเข้าครั้งแรกของประวัติศาสตร์อันยาวนานและเกี่ยวข้อง” เป็นจุดที่คุ้มค่ากับการเสียเวลาไปกับการค้นหาเดลต้าที่ดีจริงๆ จากนั้นผู้ใช้ทุกคนหลังจากนั้น (ตราบใดที่พวกเขาไม่ได้ใช้git gc --aggressiveเพื่อเลิกทำ!) จะได้รับประโยชน์จากเหตุการณ์ที่เกิดขึ้นเพียงครั้งเดียว ดังนั้นโดยเฉพาะอย่างยิ่งสำหรับโครงการขนาดใหญ่ที่มีประวัติอันยาวนานมันอาจคุ้มค่าที่จะทำงานพิเศษบางอย่างโดยบอกให้รหัสการค้นหาเดลต้าดำเนินไปอย่างรวดเร็ว

ดังนั้นสิ่งที่เทียบเท่าgit gc --aggressive- แต่ทำอย่างถูกต้อง - คือการทำ (ค้างคืน) อย่าง

git repack -a -d --depth=250 --window=250

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

และที่นี่คุณอาจต้องการเพิ่ม-fแฟล็ก (ซึ่งก็คือ "ทิ้งเดลต้าเก่าทั้งหมด" เนื่องจากตอนนี้คุณกำลังพยายามทำให้แน่ใจว่าอันนี้พบผู้สมัครที่ดีจริงๆ

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

          Linus

ฉันควรใช้ gc & repack เมื่อใด

ดังที่ฉันได้กล่าวไว้ใน " Git Garbage collection ดูเหมือนจะทำงานไม่เต็มที่ " a git gc --aggressiveนั้นไม่เพียงพอหรือเพียงพอด้วยตัวมันเอง
และตามที่ฉันอธิบายไว้ด้านล่างมักไม่จำเป็น

ชุดค่าผสมที่มีประสิทธิภาพมากที่สุดคือการเพิ่มgit repackแต่ยังgit prune:

git gc
git repack -Ad      # kills in-pack garbage
git prune           # kills loose garbage

หมายเหตุ: Git 2.11 (Q4 2016) จะตั้งค่าgc aggressiveความลึกเริ่มต้นเป็น 50

ดูกระทำ 07e7dbf (11 สิงหาคม 2016) โดยเจฟฟ์คิง (peff )
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 0952ca8 , 21 กันยายน 2016)}

gc: เริ่มต้นความลึกเชิงรุกเป็น 50

" git gc --aggressive" ใช้เพื่อจำกัดความยาวเดลต้าเชนไว้ที่ 250 ซึ่งลึกเกินไปสำหรับการประหยัดพื้นที่เพิ่มเติมและเป็นอันตรายต่อประสิทธิภาพของรันไทม์
ขีด จำกัด ลดลงเหลือ 50

สรุปคือค่าเริ่มต้นปัจจุบันคือ 250 ไม่ช่วยประหยัดพื้นที่มากนักและต้นทุน CPU มันไม่ใช่การแลกเปลี่ยนที่ดี

การ--aggressiveตั้งค่าสถานะ "" เพื่อgit-gcทำสามสิ่ง:

1. ใช้ " -f" เพื่อทิ้งเดลต้าที่มีอยู่และคำนวณใหม่ตั้งแต่ต้น
2. ใช้ "--window = 250" เพื่อให้ดูยากขึ้นสำหรับเดลต้า
3. ใช้ "--depth = 250" เพื่อสร้างเดลต้าเชนที่ยาวขึ้น

รายการ (1) และ (2) เข้ากันได้ดีสำหรับการบรรจุหีบห่อแบบ "ก้าวร้าว"
พวกเขาขอให้ repack ทำงานด้านการคำนวณมากขึ้นโดยหวังว่าจะได้แพ็คที่ดีขึ้น คุณจ่ายค่าใช้จ่ายในระหว่างการบรรจุหีบห่อและการดำเนินการอื่น ๆ จะเห็นเฉพาะผลประโยชน์

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

(ดูข้อผูกพันสำหรับการศึกษา )

คุณจะเห็นได้ว่าการประหยัด CPU สำหรับการทำงานปกติจะดีขึ้นเมื่อเราลดความลึกลง
แต่เรายังสามารถเห็นได้ว่าการประหยัดพื้นที่นั้นไม่มากนักเนื่องจากความลึกจะสูงขึ้น การประหยัด 5-10% ระหว่าง 10 ถึง 50 น่าจะคุ้มค่ากับการแลกเปลี่ยน CPU การประหยัด 1% ไปจาก 50 เป็น 100 หรืออีก 0.5% จาก 100 เป็น 250 นั้นอาจจะไม่ได้

เมื่อพูดถึงการประหยัด CPU " git repack" ได้เรียนรู้ที่จะยอมรับ--threads=<n>ตัวเลือกและส่งต่อไปยังแพ็คอ็อบเจกต์

ดูกระทำ 40bcf31 (26 เมษายน 2017) โดยJunio C Hamano (gitster )
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 31fb6f4 , 29 พฤษภาคม 2017)}

บรรจุใหม่: ยอมรับ--threads=<n>และส่งต่อไปยังpack-objects

เราทำเพื่อ--window=<n>และ--depth=<n>; สิ่งนี้จะช่วยได้เมื่อผู้ใช้ต้องการบังคับ--threads=1ให้ทำการทดสอบซ้ำโดยไม่ได้รับผลกระทบจากการแข่งหลายเธรด

ปัญหาgit gc --aggressiveคือชื่อตัวเลือกและเอกสารประกอบทำให้เข้าใจผิด

ตามที่Linus อธิบายไว้ในจดหมายฉบับนี้สิ่งที่git gc --aggressiveทำโดยพื้นฐานคือ:

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

โดยปกติแล้วไม่จำเป็นต้องคำนวณเดลต้าใหม่ในคอมไพล์เนื่องจากคอมไพล์กำหนดเดลต้าเหล่านี้มีความยืดหยุ่นมาก มันจะสมเหตุสมผลก็ต่อเมื่อคุณรู้ว่าคุณมีเดลต้าที่แย่มากจริงๆ ตามที่ Linus อธิบายส่วนใหญ่เป็นเครื่องมือที่ใช้ประโยชน์จากgit fast-importหมวดหมู่นี้

เวลาส่วนใหญ่ git ทำงานได้ค่อนข้างดีในการกำหนดเดลต้าที่มีประโยชน์และการใช้git gc --aggressiveจะทำให้คุณมีเดลต้าซึ่งอาจแย่ลงไปอีกในขณะที่เสียเวลา CPU ไปมาก

ไลนัสปิดท้ายจดหมายของเขาด้วยข้อสรุปว่าgit repackมีขนาดใหญ่--depthและ--windowเป็นทางเลือกที่ดีกว่าในช่วงเวลาส่วนใหญ่ โดยเฉพาะอย่างยิ่งหลังจากที่คุณนำเข้าโปรเจ็กต์ขนาดใหญ่และต้องการให้คอมไพล์พบเดลต้าที่ดี

ดังนั้นสิ่งที่เทียบเท่าgit gc --aggressive- แต่ทำอย่างถูกต้อง - คือการทำอะไรสักอย่าง (ค้างคืน)

git repack -a -d --depth=250 --window=250

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

และที่นี่คุณอาจต้องการเพิ่ม-fแฟล็ก (ซึ่งก็คือ "ลบเดลต้าเก่าทั้งหมด" เนื่องจากตอนนี้คุณกำลังพยายามทำให้แน่ใจว่าอันนี้พบผู้สมัครที่ดีจริงๆ

ข้อควรระวัง. อย่ารันgit gc --agressiveกับที่เก็บซึ่งไม่ซิงโครไนซ์กับรีโมตหากคุณไม่มีการสำรองข้อมูล

การดำเนินการนี้จะสร้างเดลต้าขึ้นใหม่ตั้งแต่ต้นและอาจทำให้ข้อมูลสูญหายได้หากถูกขัดจังหวะอย่างสง่างาม

สำหรับคอมพิวเตอร์ 8GB ที่ก้าวร้าว gc ของฉันไม่มีหน่วยความจำบนที่เก็บ 1Gb พร้อมคอมมิตขนาดเล็ก 10k เมื่อนักฆ่า OOM ยุติกระบวนการคอมไพล์ - มันทำให้ฉันมีพื้นที่เก็บข้อมูลที่เกือบว่างเปล่ามีเพียงต้นไม้ที่ใช้งานได้และเดลต้าเพียงไม่กี่แห่งเท่านั้นที่รอดชีวิต

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

หมายเหตุ: ระวังการใช้git gc --aggressiveเนื่องจาก Git 2.22 (Q2 2019) ชี้แจง

ดูกระทำ 0044f77 , กระทำ daecbf2 , กระทำ 7384504 , กระทำ 22d4e3b , กระทำ 080a448 , กระทำ 54d56f5 , กระทำ d257e0f , กระทำ b6a8d09 (7 เมษายน 2019) และกระทำ fc559fb , กระทำ cf9cd77 , กระทำ b11e856 (22 มีนาคม 2019) โดยÆvar Arnfjord Bjarmason ( avar) .
^{(ผสานโดยJunio ​​C Hamano - gitster-ในการกระทำ ac70c53 , 25 เม.ย. 2019)}

gc เอกสาร: แสดงความเป็นประโยชน์ของ --aggressive

gc --aggressiveเอกสาร " " ที่มีอยู่ไม่ได้แนะนำให้ผู้ใช้เรียกใช้เป็นประจำ
ก็เคยพูดคุยเป็นการส่วนตัวกับผู้ใช้งานหลายคนได้นำเอกสารเหล่านี้เป็นคำแนะนำที่จะใช้ตัวเลือกนี้และมักจะมัน (ส่วนใหญ่) เสียเวลา

ดังนั้นเรามาชี้แจงว่ามันทำอะไรได้จริงและให้ผู้ใช้สรุปเอง

Let 's ยังชี้แจง "ผล [ ... ] ถาวร" ถอดความรุ่นโดยย่อของคำอธิบายเจฟฟ์ของพระบาทสมเด็จพระเจ้าอยู่หัว

นั่นหมายความว่าตอนนี้เอกสาร git-gc ประกอบด้วย :

ก้าวร้าว

เมื่อ--aggressiveตัวเลือกจะถูกส่งให้git-repackจะถูกเรียกด้วย-fธงซึ่งในทางกลับจะผ่าน--no-reuse-deltaการคอมไพล์แพ็ควัตถุ
สิ่งนี้จะทิ้งเดลต้าที่มีอยู่และคำนวณใหม่โดยเสียเวลาในการบรรจุใหม่มากขึ้น

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

นอกจากนี้การจัดหา--aggressiveจะปรับแต่ง--depthและตัวเลือกการส่งผ่านไปยัง--window ดูและการตั้งค่าด้านล่าง ด้วยการใช้ขนาดหน้าต่างที่ใหญ่ขึ้นเราจึงมีแนวโน้มที่จะพบเดลต้าที่เหมาะสมมากขึ้นgit-repack
gc.aggressiveDepthgc.aggressiveWindow

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

และ ( กระทำ 080a448 ):

gcเอกสาร: สังเกตว่า--aggressiveผลกระทบ--window&--depth

ตั้งแต่07e7dbf ( gc: ความลึกเชิงรุกเริ่มต้นเป็น 50, 2016-08-11, Git v2.10.1) เราค่อนข้างสับสนในการใช้ความลึกเดียวกันภายใต้--aggressiveตามที่เราทำโดยค่าเริ่มต้น

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