it-swarm.com.de

Der Pfad des git-Submoduls kann nicht ausgecheckt werden

Ich habe ein Problem bei der Arbeit mit Git-Submodulen.

Immer wenn ich eine neue Submodulreferenz vom Upstream-Repository erhalte, führt die Ausführung von git submodule update zu folgendem Ergebnis:

fatal: reference is not a tree: dd208d46ecdd1ac0d2b2594a610fe4c9150fece1
Unable to checkout 'dd208d46ecdd1ac0d2b2594a610fe4c9150fece1' in submodule path 'submodule/path'

Es ist wichtig zu beachten, dass das Submodul mehrere Fernbedienungen besitzt, von denen die Upstream-Fernbedienung zur Aktualisierung des Submodul-Referenzbaums verwendet werden sollte. Ich vermute, dass mein Problem da ist, aber ich bin mir nicht sicher.

Mein Setup ist das Folgende:

Git Projekt

Fernbedienungen:

  1. Origin (meine Git-Gabel)
  2. upstream (Projekt-Repo)

Submodul "Modul" hat Fernbedienungen:

  1. Origin (meine Git-Gabel)
  2. upstream (Projekt-Repo)

Weiß jemand, was mein Problem verursacht?

31
Richard Tuin

Wenn Sie git submodule update ausführen, versucht git, den im Superprojekt gespeicherten Commit/Baum zu überprüfen (in Ihrem Beispiel der mit der Festschreibungs-ID dd208d4...).

Ich denke, Sie erhalten den Fehler, weil innerhalb des Submoduls kein Objekt vorhanden ist. Sie müssen sicherstellen, dass es da ist. In der Regel bedeutet dies, dass Sie es zuerst von einer Fernbedienung abrufen/ziehen müssen.

Wahrscheinlich musst du

git submodule foreach git fetch
git submodule update

oder vielleicht

git fetch --recurse-submodules

Angenommen, das Submodul ist so konfiguriert, dass es das fehlende Commit von der entfernten Origin abrufen kann. Am Ende muss du wissen, woher du das fehlende Commit holen kannst und du musst es bekommen.

Sie können überprüfen, ob Sie dd208d4... haben, indem Sie Folgendes tun:

cd ./module
git log dd208d46ecdd1ac0d2b2594a610fe4c9150fece1
git cat-file -p dd208d46ecdd1ac0d2b2594a610fe4c9150fece1
git ls-tree dd208d46ecdd1ac0d2b2594a610fe4c9150fece1

Eine mögliche Ursache für ein solches Problem besteht darin, dass derjenige, der das neue Commit aus dem Supermodul herausgegeben hat, die erforderlichen Commits aus dem Submodul nicht veröffentlicht hat. Er muss zuerst die Commits aus dem Submodul veröffentlichen.

36
thaller

Vergewissere dich, dass die Submodule geschoben wurden

cd submodule-dir
git Push

In meinem Fall hatte ich:

  • dem Submodul verpflichtet
  • nicht geschoben
  • mit den aktualisierten Submodulen an den Elternteil übergeben
  • schob den Elternteil

kein Wunder also, dass es nicht gefunden werden konnte.

Wenn Sie eine Webschnittstelle wie GitHub verwenden, können Sie auch auf die Submodul-Repository-Webseite gehen und dort überprüfen, ob der erforderliche Commit angezeigt wird.

Push.recurseSubmodules on-demand

Es ist möglich, Pushs weiter zu automatisieren:

git Push --recurse-submodules=on-demand

die auch Submodule nach Bedarf schiebt oder mit 2.7 beginnt:

git config Push.recurseSubmodules on-demand
git Push

ich habe gerade dieses Problem gesehen, als ich vergessen habe, die Änderungen in einem meiner Submodule zu verschieben

stellen Sie sicher, dass die Änderungen übernommen werden

1
Aleksey Bykov

Ich hatte das gleiche Problem und habe das Hinzufügen eines neuen Commits für das übergeordnete Projekt und Push all behobenCheck the Subproject commit and commit from your module

1
protonss

Mein Problem ist, dass ich auf einen cat .gitmodules meines Repos auf die falsche Fernbedienung für das Repo des Submoduls verwies (ich hatte es ursprünglich mit der Originalfernbedienung geklont, aber dann auf einen Zweig davon umgestiegen; die gitmodules - Datei wurde nie aktualisiert, um die Veränderung).

0
Ben Kreeger

Mein Problem war, dass ich nicht festgeschriebene Änderungen an den Submodulen in ihren build.gradle -Dateien hatte (die meiner Meinung nach automatisch geändert wurden). Sie tauchten im git diff auf. Ich habe gerade git checkout . gemacht, um die Submodul-Repos zurückzusetzen, um keine Änderungen vorzunehmen, und dann hat der git submodule update funktioniert.

0
Rock Lee

Das Hinzufügen von git rm --cached <submodule-directory> Hilft mir bei gitlab:

.prepare_deploy: &prepare_deploy
  before_script:
    - bundle install -j $(nproc) --path vendor
    - which ssh-agent || (apt-get update -y && apt-get install openssh-client -y)
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - eval $(ssh-agent -s)
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - (echo "$SSH_PRIVATE_KEY" | base64 --decode) > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - git rm --cached <submodule-directory>
    - git submodule sync --recursive
    - git submodule update --init --recursive
0
c80609a

Ein anderer Weg könnte sein, ohne die Befehlszeilengitoptionen, aber dies manuell zu tun. Das Szenario tritt meist dann auf, wenn die Submodulpfade verschoben/ersetzt wurden (aber nicht richtig), wodurch auf die alten Referenzen verwiesen wird in den lokalen Checkout-Repositories.

1) Lokalisieren Sie das Repository und das Submodul

ls -la .git/modules
   rm -f .git/modules/<module-with-issue>

2) Entfernen Sie die älteren lokalen Submodul-Konfigurationen

 gedit .git/config

(Entfernen Sie den URL-Eintrag des Submoduls hier.)

Es sieht ungefähr so ​​aus;

 *[submodule "module-with-issue"]
       url = ...*

3) Jetzt die Submodule neu abrufen und aktualisieren Git holen git submodule update --recursive --init

Hinweis: Möglicherweise müssen Sie zusätzlich den lokal ausgecheckten Submodulordner in Ihrem Repository entfernen, bevor Sie ein Submodul-Update durchführen.

0
parasrish