Ich versuche, einen Checkout von GitHub durchzuführen und erhalte diese Fehlermeldung:
[user@arch ~]$ git clone --recursive https://github.com/simsong/tcpflow.git
Cloning into 'tcpflow'...
The authenticity of host 'github.com (192.30.253.113)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,192.30.253.113' (RSA) to the list of known hosts.
remote: Counting objects: 4190, done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 4190 (delta 21), reused 29 (delta 12), pack-reused 4146
Receiving objects: 100% (4190/4190), 50.27 MiB | 2.21 MiB/s, done.
Resolving deltas: 100% (2954/2954), done.
Submodule 'src/be13_api' (https://github.com/simsong/be13_api.git) registered for path 'src/be13_api'
Submodule 'src/dfxml' (https://github.com/simsong/dfxml.git) registered for path 'src/dfxml'
Submodule 'src/http-parser' (https://github.com/nodejs/http-parser.git) registered for path 'src/http-parser'
Cloning into '/home/user/tcpflow/src/be13_api'...
remote: Counting objects: 1203, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 1203 (delta 2), reused 5 (delta 1), pack-reused 1194
Receiving objects: 100% (1203/1203), 477.47 KiB | 1.96 MiB/s, done.
Resolving deltas: 100% (821/821), done.
Cloning into '/home/user/tcpflow/src/dfxml'...
remote: Counting objects: 1929, done.
remote: Total 1929 (delta 0), reused 0 (delta 0), pack-reused 1929
Receiving objects: 100% (1929/1929), 572.09 KiB | 2.89 MiB/s, done.
Resolving deltas: 100% (1294/1294), done.
Cloning into '/home/user/tcpflow/src/http-parser'...
remote: Counting objects: 1487, done.
remote: Total 1487 (delta 0), reused 0 (delta 0), pack-reused 1487
Receiving objects: 100% (1487/1487), 667.24 KiB | 2.46 MiB/s, done.
Resolving deltas: 100% (916/916), done.
Submodule path 'src/be13_api': checked out 'c81521d768bb78499c069fcd7c47adc8eee0350c'
Submodule path 'src/dfxml': checked out 'c31224626cf5f6678d42cbcfbfcd4e6191c9a864'
error: Server does not allow request for unadvertised object 5bbcdc5df9d01b521e8da011bab0da70bdec3653
Fetched in submodule path 'src/http-parser', but it did not contain 5bbcdc5df9d01b521e8da011bab0da70bdec3653. Direct fetching of that commit failed.
[user@arch ~]$
Ich bin also der Betreuer dieser Repos. Der src/http-parser ist ein Fork eines anderen Repos, und die Betreuer dieses Repos haben meine Pull Requests, der Datei einige automatisch generierte Dateien hinzuzufügen, konsequent abgelehnt (ohne Angabe von Gründen) .gitignore. Aber ich glaube nicht, dass das hier das Problem ist.
Antwort1
jgit – Was sind die angekündigten Referenzen von Git? – Stack Overflow:
Während eines Abrufvorgangs kann der Server Referenzen auflisten, die er hat und die der Client möglicherweise abrufen möchte. Dies sind die angekündigten Referenzen.
- Es sieht aus wieSie können kein einzelnes bestimmtes Commit direkt vom Server abrufen, sondern nur Referenzen (d. h. Zweige und Tags).Oder besser gesagt, dass die Github-Server so konfiguriert sind, dass solche Anfragen nicht zugelassen werden.
Also,wenn Sie ein bestimmtes Commit erhalten möchten mit
--depth, es darf höchstens<depth>-1Commits vom abgerufenen Ref entfernt sein(das ist der in den Metadaten des Untermoduls angegebene Zweig/Tag)Normalerweise wird empfohlen, einfach
deptheine Zahl festzulegen, die einigermaßen groß, aber immer noch viel kleiner als die Gesamtzahl der Commits im Repo ist – etwa50oder100. Dies50ist das, was Travis verwendet, wenn er den ersten Klon für das Projekt erstellt.
Wenn Sie das Untermodul nicht mit aktualisieren --depth, kann das Nichtauffinden des Commits Folgendes bedeuten:
- der Baum des Untermoduls befindet sich im "flachen" Zustand und das oben genannte gilt (nur möglich, wenn er zuvor mit
--depthoder aktualisiert wurdesein Eintritt in.gitmoduleshatshallow = true) - Das Commit befindet sich nicht auf dem Branch, den das Submodul verwendet.
- das Commit befindet sich überhaupt nicht im Repo des Untermoduls:
- Entweder hat jemand einen Fehler gemacht,
- oder es war einmal da, wurde aber durch einen erzwungenen Push gelöscht
Zur Klarstellung: In Ihrem speziellen Fall war es der letzte Fall: Das Commit befindet sich überhaupt 5bbcdc5df9d01b521e8da011bab0da70bdec3653nicht im Repo.https://github.com/simsong/http-parser.git
Antwort2
Eine Möglichkeit, Zugriff auf ein nicht angekündigtes Objekt zu erhalten, ist die Synchronisierung. Dann sollte ein Submodul-Update wie folgt funktionieren:
git submodule sync --recursive
git submodule update
Antwort3
Dies kann passieren, wenn Sie auf ein Submodul-Commit verweisen, das durch eine Verlaufsumschreibung oder Squash entfernt wurde. Das Beste, was Sie tun können, ist:
- Machen Sie sich zunächst ein klares Bild von den bisherigen Aufgaben Ihres Teams, damit Sie wissen, wie diese aussehen sollen.
- Aktualisieren Sie Ihre lokale Version mit einem „Git Pull“, suchen Sie dann nach dem nächstgelegenen Commit, der mit Ihrem Branch funktioniert (möglicherweise ist es das neuste), und fügen Sie diesen dann zu Ihrem übergeordneten Repo hinzu. Beispielsweise so etwas wie:
parent-repo$ git fetch
parent-repo$ cd submodule-a
submodule-a$ git pull
submodule-a$ git checkout best-commit-according-to-team-and-your-branch
submodule-a$ cd ../
parent-repo$ git status
...
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
(commit or discard the untracked or modified content in submodules)
modified: submodule-a (modified content)
...
git add submodule-a
git commit -m "updated submodule-a reference"
Wenn Sie mit der Richtigkeit zufrieden sind und Ihr Team einverstanden ist, können Sie es nach oben verschieben, und der Fehler sollte behoben sein.
Antwort4
Bei mir passiert dies in der Regel, wenn ich ein übergeordnetes Git-Repository zurück zu GitHub pushe, ohne ein Untermodul zurückzupushen, das ich geändert und festgeschrieben, aber nicht zurückgepusht habe.