ฉันมีโครงการที่มี submodule ที่ชี้ไปที่การกระทำที่ไม่ถูกต้อง: submodule กระทำยังคงอยู่ในพื้นที่และเมื่อฉันพยายามที่จะดึงมันจาก repo อื่นที่ฉันได้รับ:

$ git submodule update
fatal: reference is not a tree: 2d7cfbd09fc96c04c4c41148d44ed7778add6b43
Unable to checkout '2d7cfbd09fc96c04c4c41148d44ed7778add6b43' in submodule path 'mysubmodule'

ฉันรู้ว่าสิ่ง HEAD submodule ควรจะเป็นมีวิธีที่ฉันสามารถเปลี่ยนแปลงได้ในท้องถิ่นโดยไม่ต้องผลักดันจาก repo ที่ไม่ได้กระทำ2d7cfbd09fc96c04c4c41148d44ed7778add6b43?

ฉันไม่แน่ใจว่าฉันชัดเจนหรือไม่ ... นี่เป็นสถานการณ์ที่คล้ายกันที่ฉันพบ

สมมติว่าที่เก็บของ submodule มีคอมมิทที่คุณต้องการใช้ (ไม่เหมือนกับคอมมิทที่อ้างอิงจากสถานะปัจจุบันของโปรเจ็กต์สุด) มีสองวิธีในการทำ

ก่อนอื่นคุณต้องทราบความมุ่งมั่นจาก submodule ที่คุณต้องการใช้ มันทำงานได้จาก "ภายในออก" โดยการปรับ submodule โดยตรงจากนั้นอัปเดตซุปเปอร์โปรเจ็กต์ ผลงานที่สองจาก“ ภายนอก” โดยการค้นหาการกระทำของโครงการพิเศษที่แก้ไข submodule แล้วทำการรีเซ็ตดัชนีของโครงการ super เพื่ออ้างอิงการส่งข้อมูลย่อยอื่น ๆ

กลับด้าน

ถ้าคุณรู้อยู่แล้วซึ่งกระทำคุณต้องการ submodule ที่จะใช้cdในการ submodule ให้ตรวจสอบการกระทำที่คุณต้องการแล้วgit addและgit commitมันกลับมาอยู่ในซุปเปอร์โครงการ

ตัวอย่าง:

$ git submodule update
fatal: reference is not a tree: e47c0a16d5909d8cb3db47c81896b8b885ae1556
Unable to checkout 'e47c0a16d5909d8cb3db47c81896b8b885ae1556' in submodule path 'sub'

อ๊ะคนทำซุปเปอร์โครงการกระทำที่อ้างอิงถึงการที่ไม่ได้เผยแพร่กระทำใน subsubmodule อย่างใดที่เรารู้อยู่แล้วว่าเราต้องการ submodule 5d5a3ee314476701a20f2c6ec4a53f88d651df6cที่จะกระทำการที่ ไปที่นั่นและตรวจสอบโดยตรง

ชำระเงินใน Submodule

$ cd sub
$ git checkout 5d5a3ee314476701a20f2c6ec4a53f88d651df6c
Note: moving to '5d5a3ee314476701a20f2c6ec4a53f88d651df6c' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at 5d5a3ee... quux
$ cd ..

เนื่องจากเรากำลังตรวจสอบการกระทำสิ่งนี้ทำให้เกิด HEAD ที่แยกออกมาใน submodule หากคุณต้องการให้แน่ใจว่า submodule ใช้สาขาจากนั้นใช้git checkout -b newbranch <commit>เพื่อสร้างและชำระเงินสาขาที่กระทำหรือชำระเงินสาขาที่คุณต้องการ (เช่นที่มีการกระทำที่ต้องการกระทำที่ปลาย)

อัพเดท Super-project

เช็คเอาต์ใน submodule นั้นจะปรากฎใน super-project เพื่อเปลี่ยนเป็นแผนผังการทำงาน ดังนั้นเราต้องแสดงการเปลี่ยนแปลงในดัชนีของโครงการซุปเปอร์และตรวจสอบผลลัพธ์

$ git add sub

ตรวจสอบผลลัพธ์

$ git submodule update
$ git diff
$ git diff --cached
diff --git c/sub i/sub
index e47c0a1..5d5a3ee 160000
--- c/sub
+++ i/sub
@@ -1 +1 @@
-Subproject commit e47c0a16d5909d8cb3db47c81896b8b885ae1556
+Subproject commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c

การอัปเดต submodule นั้นเป็นแบบไม่โต้ตอบเนื่องจาก submodule นั้นอยู่ที่การคอมมิทที่ระบุแล้ว diff แรกแสดงให้เห็นว่าดัชนีและ worktree เหมือนกัน diff ที่สามแสดงว่าการเปลี่ยนแปลง staged เดียวคือการย้ายsubsubmodule ไปยัง commit อื่น

ผูกมัด

git commit

สิ่งนี้คอมมิตยอมรับรายการ submodule ที่แก้ไขแล้ว

ข้างนอกใน

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

$ git submodule update
fatal: reference is not a tree: e47c0a16d5909d8cb3db47c81896b8b885ae1556
Unable to checkout 'e47c0a16d5909d8cb3db47c81896b8b885ae1556' in submodule path 'sub'

นี่เป็นสถานการณ์เดียวกันกับข้างต้น แต่คราวนี้เราจะมุ่งเน้นที่การแก้ไขจาก super-project แทนที่จะจุ่มลงใน submodule

ค้นหา Erit Commit ของ Super-project

$ git log --oneline -p -- sub
ce5d37c local change in sub
diff --git a/sub b/sub
index 5d5a3ee..e47c0a1 160000
--- a/sub
+++ b/sub
@@ -1 +1 @@
-Subproject commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c
+Subproject commit e47c0a16d5909d8cb3db47c81896b8b885ae1556
bca4663 added sub
diff --git a/sub b/sub
new file mode 160000
index 0000000..5d5a3ee
--- /dev/null
+++ b/sub
@@ -0,0 +1 @@
+Subproject commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c

ตกลงดูเหมือนว่าจะไม่ดีce5d37cดังนั้นเราจะคืนค่า submodule จาก parent ( ce5d37c~)

หรือคุณสามารถใช้การส่งข้อมูลย่อยของข้อความแพทช์ ( 5d5a3ee314476701a20f2c6ec4a53f88d651df6c) และใช้กระบวนการ“ ข้างในออก” ข้างต้นแทน

ชำระเงินในโครงการซุปเปอร์

$ git checkout ce5d37c~ -- sub

นี่เป็นการรีเซ็ตรายการ submodule สำหรับsubสิ่งที่มันถูกคอมมิทce5d37c~ใน super-project

อัพเดท Submodule

$ git submodule update
Submodule path 'sub': checked out '5d5a3ee314476701a20f2c6ec4a53f88d651df6c'

การอัปเดต submodule เป็นไปด้วยดี

ตรวจสอบผลลัพธ์

$ git diff ce5d37c~ -- sub
$ git diff
$ git diff --cached
diff --git c/sub i/sub
index e47c0a1..5d5a3ee 160000
--- c/sub
+++ i/sub
@@ -1 +1 @@
-Subproject commit e47c0a16d5909d8cb3db47c81896b8b885ae1556
+Subproject commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c

ครั้งแรกที่แสดงให้เห็นถึงความแตกต่างว่าขณะนี้ในตัวเดียวกันsub ce5d37c~ส่วนต่างที่สองแสดงว่าดัชนีและ worktree เหมือนกัน ส่วนต่างที่สามแสดงให้เห็นว่าการเปลี่ยนแปลงแบบฉากเพียงอย่างเดียวคือการเคลื่อนย้ายsubsubmodule ไปยังการคอมมิทที่ต่างกัน

ผูกมัด

git commit

สิ่งนี้คอมมิตยอมรับรายการ submodule ที่แก้ไขแล้ว

ลองนี้:

git submodule sync
git submodule update

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

มีโอกาสน้อยกว่าที่จะเกิดปัญหาสิทธิ์และไม่สามารถดึงการมอบหมายได้ (เป็นไปได้หากคุณใช้ git + ssh)

ตรวจสอบให้แน่ใจว่าเส้นทาง submodule ดูเป็น ok ใน. git / config และ. gitmodules

สิ่งสุดท้ายที่ต้องลอง - ภายในไดเรกทอรี submodule: git reset HEAD --hard

สาเหตุที่เป็นไปได้

สิ่งนี้สามารถเกิดขึ้นได้เมื่อ:

1. แก้ไขโมดูลย่อยแล้ว
2. มีการมอบหมาย Submodule ซึ่งอัพเดตแฮชของ submodule ที่ถูกชี้ไป
3. ไม่ได้ผลักดันโมดูลย่อย

เช่นบางสิ่งเช่นนี้เกิดขึ้น:

$ cd submodule
$ emacs my_source_file  # edit some file(s)
$ git commit -am "Making some changes but will forget to push!"

ควรส่ง submodule ไปที่จุดนี้

$ cd .. # back to parent repository
$ git commit -am "updates to parent repository"
$ git push origin master

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

สารละลาย

Informa บุคคลที่แก้ไข submodule ที่จะผลักดันคือ

$ cd submodule
$ git push

ฉันได้รับข้อผิดพลาดนี้เมื่อฉัน:

$ git submodule update --init --depth 1

แต่ความมุ่งมั่นในโครงการหลักชี้ไปที่การกระทำก่อนหน้า

การลบโฟลเดอร์ submodule และเรียกใช้:

$ git submodule update --init

ไม่ได้แก้ปัญหา ฉันลบ repo และลองอีกครั้งโดยไม่ใช้ธงความลึกและใช้งานได้

ข้อผิดพลาดนี้เกิดขึ้นใน Ubuntu 16.04 git 2.7.4 แต่ไม่ใช่ใน Ubuntu 18.04 git 2.17, TODO ค้นหาการแก้ไขที่แน่นอนหรือเวอร์ชั่น

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

สาขาของคุณอาจไม่ทันสมัย ​​แต่เป็นวิธีง่ายๆ git fetch

คำตอบนี้สำหรับผู้ใช้ของ SourceTree ที่มีประสบการณ์การใช้งานเทอร์มินอล git จำกัด

เปิด submodule ที่มีปัญหาจากภายในโครงการ Git (super-project)

ดึงข้อมูลและตรวจสอบให้แน่ใจว่าได้เลือก 'ดึงแท็กทั้งหมด'

Rebase ดึงโครงการ Git ของคุณ

สิ่งนี้จะแก้ปัญหา 'การอ้างอิงไม่ใช่ต้นไม้' ปัญหา 9 จากสิบครั้ง ครั้งที่ 1 มันจะไม่เป็นเทอร์มินัลแก้ไขตามที่อธิบายโดยคำตอบด้านบน

ประวัติ submodule ของคุณจะถูกเก็บรักษาไว้อย่างปลอดภัยใน git submodule ต่อไป

ดังนั้นทำไมไม่เพียงแค่ลบ submodule และเพิ่มอีกครั้ง?

มิฉะนั้นคุณลองแก้ไขด้วยตนเองHEADหรือrefs/master/headภายใน submodule.git

เพียงเพื่อให้แน่ใจว่าลองอัปเดตgitไบนารีของคุณ

GitHub สำหรับ Windows มีรุ่นgit version 1.8.4.msysgit.0ซึ่งในกรณีของฉันเป็นปัญหา การอัปเดตแก้ไขมัน

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

1. ไปที่ submodule ของ dir:

   cd sub
   

2. ชำระเงินให้หลัก:

   git checkout master
   

3. rebase เป็นรหัสการยอมรับซึ่งลูกค้าทั้งสองสามารถมองเห็น

4. กลับไปที่ dir ของผู้ปกครอง:

5. มุ่งมั่นที่จะโท

6. เปลี่ยนเป็นไคลเอนต์อื่นทำrebaseอีกครั้ง

7. ในที่สุดมันก็ทำงานได้ดีในขณะนี้! อาจสูญเสียการผูกไว้สองครั้ง แต่ใช้งานได้

8. FYI อย่าพยายามลบ submodule ของคุณมันจะยังอยู่ที่.git/modulesนั่นและไม่สามารถอ่าน submodule นี้ได้อีกเว้นแต่ว่าจะมีปฏิกิริยาแบบโลคอล

เมื่อต้องการซิงค์ git repo กับส่วนหัวของ submodule ในกรณีที่เป็นสิ่งที่คุณต้องการจริงๆฉันพบว่าการลบ submodule แล้วอ่านมันเพื่อหลีกเลี่ยงการแก้ไขด้วยประวัติศาสตร์ น่าเสียดายที่การลบ submodule ต้องการการแฮ็กแทนที่จะเป็นคำสั่ง git เพียงคำเดียว แต่ทำได้

ขั้นตอนที่ฉันติดตามเพื่อลบ submodule ซึ่งได้รับแรงบันดาลใจจากhttps://gist.github.com/kyleturner/1563153 :

1. เรียกใช้ git rm --cached
2. ลบบรรทัดที่เกี่ยวข้องออกจากไฟล์. gitmodules
3. ลบส่วนที่เกี่ยวข้องออกจาก. git / config
4. ลบไฟล์ submodule ที่ไม่ได้ติดตามตอนนี้
5. ลบไดเรกทอรี. git / modules /

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

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

เพิ่งสะดุดกับปัญหานี้และไม่มีวิธีแก้ปัญหาเหล่านี้สำหรับฉัน สิ่งที่จะเป็นทางออกสำหรับปัญหาของฉันได้ง่ายกว่ามาก: อัพเกรด Git ฉันเป็น 1.7.1 และหลังจากฉันอัพเกรดเป็น 2.16.1 (ล่าสุด) ปัญหาก็หายไปอย่างไร้ร่องรอย! คิดว่าฉันจะทิ้งมันไว้ที่นี่หวังว่ามันจะช่วยใครซักคน