git Submodul hat "neue Commits", wenn ich Kasse

Question

Ich habe ein Submodul namens Helfer. Wenn ich mein Hauptprojekt mit --recursive kloniere, ist das Hilfs-Submodul in einem losgelösten Kopfzustand (wie alle Tutorials sagen). Wenn ich jetzt im Hauptprojektverzeichnis "Status" gitriere, ist alles sauber. Wenn ich Helfer helfe; Ich würde erwarten, dass sich nichts ändert, außer dass ich jetzt in einem benannten Zweig bin, zu dem ich mich verpflichten kann. Allerdings, ohne etwas anderes zu tun, wenn ich cd ..; git status ', sehe ich

modified: Helpers (new commits) 

Warum denkt es, es gibt neue Commits? Das Submodul sollte immer noch an dem Punkt sein, an dem es aktualisiert wurde (in diesem Fall geklont), nein?

Answer 1

Wenn das HEAD Ihres Submoduls nicht mit dem Commit übereinstimmt, das im Index des übergeordneten Repositorys angegeben wurde, gibt git Ihnen die Nachricht "new commits". Sie können überprüfen, welche im Index wird durch das Ausführen git ls-tree commit angegeben:

$ git ls-tree master:<path_to_folder_containing_my_submodule> 
160000 commit ba9d11670daf5109a52e5a2b01bca8a344897338 my_submodule 

Wenn Sie eine rekursive git clone tun, git wird die neueste holen und dann HEAD auf den Punkt angegeben begehen. Wenn das angegebene Commit nicht mit dem letzten Commit im Remote-Master übereinstimmt, entspricht master beim Klonen nicht HEAD.

Eine weitere Möglichkeit, zu überprüfen, nachdem Sie eine rekursive Klon tun, um cd in Ihre Submodul ist und dann verwenden git log:

$ git log --decorate --all 
commit 6a75034cc78fc637e2437bba9f5834835f56bd8f (origin/master, origin/HEAD, master) 
... 
commit ba9d11670daf5109a52e5a2b01bca8a344897338 (HEAD) 

Wenn HEAD und master Punkt zum begehen gleichen, dann können Sie Master-Kasse und Sie werden nicht Siehe die Nachricht "neue Commits" im übergeordneten Repo.

Answer 2

Was wahrscheinlich passiert ist, dass die master Ihres Submoduls nicht die Version ist, die Ihr Repo halten möchte.

Ihr Modul in die Fassung gesetzt, dass der Halt Repo will:

holding/ $ git submodule update 

die gewünschte SHA1 des Submoduls Check:

holding/ $ git submodule  # (1) 
<list of all submodules, with the desired SHA1> 

prüfen, was master Ihre Submodul lautet:

holding/ $ cd sub 
holding/sub $ git checkout master 
holding/sub $ git log -1  # (2) 

Ist die SHA1 bei (2) das gleiche wie das, was Sie bei (1) gesehen haben? Wenn nicht, ist das dein Problem. Etwas ist im Master des Submoduls passiert, aber diese neuen Änderungen wurden nicht in das Holding Repo aufgenommen.

Das Holding Repo behält eine SHA1 als Verweis auf die Version des Submoduls zu verwenden. Wenn im Repo des Submoduls eine Weiterentwicklung stattfindet, behält das Holding Repo immer noch die gleiche Version bei, es aktualisiert das Submodul nicht automatisch.

Wenn Sie eine neuere Version (z. B. master) des Submoduls auschecken und dann zum Holding Repo zurückkehren, wird Ihnen git status mitteilen, dass Sie ein neues Commit in Ihrem Submodul ausgecheckt haben. Diese Änderung des aktuellen Submodul Commit kann in Ihrem Holding Repo begangen werden. Das würde aktualisieren, welche Version des Submoduls mit diesem Festhalten verwendet werden soll.

---

Wenn Sie die Arbeit an dem Submodul fortgesetzt werden sollen, von der Version, die der Holding-Repo will, müssen Sie einen neuen Zweig erstellen. master spiegelt die weitere Entwicklung im Repo des Submoduls wider, also arbeiten Sie entweder von master (und schließen sowohl diese Weiterentwicklung als auch Ihre neue Arbeit ein), oder Sie erstellen einen neuen Zweig aus dem abgetrennten Kopf, auf den sich das Halten bezieht.

Wenn Sie master auf dem gelösten Kopf erzwingen wollten, der durch Halten gehalten wird, was würde mit den commits geschehen (weitere Entwicklung), die zwischen dem gelösten Kopf und master erzeugt wurden? Sie wären verloren. Und was passiert beim nächsten Mal, wenn Sie Ihre bewegte master auf origin schieben? Es würde einen Konflikt geben, da Ihr lokaler master von origins divergiert hätte.