Git-Klon schlägt mit „fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed“ unter MacOS Mojave fehl

Ich habe letzte Nacht viele Operationen auf meinem Computer durchgeführt, im Grunde Aktualisierung/Upgrade(?) von Brew, wodurch eine neue Git-Version installiert, Python aktualisiert, viele Sachen und heute dachte ich, ich könnte kein Repository mehr klonen.

git clone git@github.com:UnlyEd/serverless-plugin-dynamodb-backups.git
Cloning into 'serverless-plugin-dynamodb-backups'...
remote: Enumerating objects: 589, done.
remote: Total 589 (delta 0), reused 0 (delta 0), pack-reused 589
Receiving objects: 100% (589/589), 304.18 KiB | 862.00 KiB/s, done.
Resolving deltas: 100% (333/333), done.
fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed

Ich habe verschiedene Repos ausprobiert, ich bekomme jedes Mal den gleichen Fehler, also ist es meine Installation, die irgendwie kaputt ist.

Ich habe versucht, git (mit Brew) zu deinstallieren/neu zu installieren, aber es hat nichts geändert.

Ich habe andere Git-Befehle überprüft und kann immer noch ziehen/commiten

Ich verwende Git 2.21.0

Ich weiß nicht wirklich, was ich tun soll, um es zu beheben, und ich weiß nicht, was das verursacht hat. Außerdem verwende ich den Befehl git clone nicht täglich, sodass er vorher kaputt gegangen sein könnte, aber ich habe das Gefühl, dass er mit dem Upgrade von Homebrew zusammenhängt.

Hinzufügen weiterer Details basierend auf Kommentaren/Fragen:

type git
git is an alias for LANG=en_GB git

mkdir ~/gitclone && cd ~/gitclone && git clone git@github.com:UnlyEd/serverless-plugin-dynamodb-backups.git
Cloning into 'serverless-plugin-dynamodb-backups'...
remote: Enumerating objects: 589, done.
remote: Total 589 (delta 0), reused 0 (delta 0), pack-reused 589
Receiving objects: 100% (589/589), 304.18 KiB | 828.00 KiB/s, done.
Resolving deltas: 100% (333/333), done.
fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed
Was gibt ˋtype gitˋ zurück? Was passiert, wenn Sie ˋmkdir ~/gitclone && cd ~/gitclone && git clone NAMEOFREMOTEREPˋ ausführen?
@nohillside Ich habe die von Ihnen angeforderte Ausgabe hinzugefügt. Nichts Außergewöhnliches würde ich für gitdas Kommando sagen. Scheint, als ob das Problem auch nicht mit einem bestimmten Ordner zusammenhängt, sondern systemweit.

Antworten (2)

Haben Sie eine benutzerdefinierte .gitconfig? Ich musste den folgenden Parameter aus meinem entfernen, damit das Klonen wieder funktioniert:

[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*

git v2.21.0wurde vor ein paar Tagen veröffentlicht, also hat sich vielleicht etwas unter der Haube geändert. Ich muss mir die Release Notes ansehen.

Wie auch immer, hoffe das hilft!

Diese Zeile, die etwas mehr Hintergrundkontext hinzufügt, war sehr häufig, um die Tags standardmäßig abzurufen. Erlaubt, git fetchdas würde auch ein git fetch --tagsÄquivalent unter der Haube machen.

git fetchWenn Sie Tags abrufen möchten, wenn Sie mit dieser Git-Version v2.21 arbeiten , können Sie .gitconfigim Grunde wie folgt einen Alias ​​in Ihrem erstellen:

[alias]
    fetch = git fetch --tags

Wenn Sie dies tun und entfernen, fetch = +refs/heads/*:refs/remotes/origin/*wird das gleiche Verhalten erzielt, ist jedoch mit git v2.21 kompatibel

Siehe https://stackoverflow.com/questions/1204190/does-git-fetch-tags-include-git-fetch/20608181#20608181 für ausführliche Erläuterungen und Verlaufsänderungen.

In der Tat! Das war der Grund :) Danke! Kann das Kopfgeld aufgrund der SO-Richtlinie noch nicht gewähren, aber du hast es verstanden, Jon, es funktioniert wieder
Und ich weiß nicht einmal, was diese Konfiguration remote "origin"tun sollte, ich hatte sie, weil ein Kollege sie vor Jahren benutzte, und ich behielt sie, weil warum nicht. Vielleicht eine gute Übung mit der alten Git-Binärdatei, würde aber gerne wissen, wofür sie ist und ob ich sie durch etwas anderes ersetzen sollte;)
Ich bin mir auch nicht ganz sicher. Hier ist eine Dokumentation zu refspec . Vielleicht kann jemand, der schlauer ist als wir, weitere Einblicke geben :)
Scheint so, als ob es beabsichtigt war, die Tags beim Ausführen standardmäßig abzurufen, git fetchohne dies manuell tun zu müssen git fetch --tags, siehe stackoverflow.com/questions/16678072/…
Ein weiterer ausführlicher Link, sehr erklärend: stackoverflow.com/questions/1204190/…
Ich habe Ihre Antwort aktualisiert, um mehr Hintergrundinformationen hinzuzufügen und die für v2.21 erforderliche Konfiguration zu erläutern, was zum vorherigen Verhalten führt! :) (hatte Hilfe von Freunden, um es herauszufinden :D)
Ich bin verwirrt, also erlaubt Git jetzt, integrierte Befehle zu überschreiben? Bisher waren Aliase für eingebaute Befehle (wie etwa ) explizit nichtfetch erlaubt .
Beachten Sie, dass im Gegensatz zur Refspec git fetch --tagskeine aktualisierten Tags abgerufen werden. Ich kenne keinen guten Weg, um diesen Fehler beim Klonen nicht zu erhalten und aktualisierte Tags abzurufen.

Ich bin mir nicht sicher, ob dies hier das Problem ist, aber haben Sie überprüft, ob der Ordner, in den Sie klonen möchten, leer ist? Überprüfen Sie auch, ob der Ordner, in den Sie zu klonen versuchen, bereits von einem anderen Git-Repository verwaltet wird.

Sie können überprüfen, ob es sich um ein Git-Repository handelt, indem Sie Folgendes tun git statusund sehen, dass es so sein sollte fatal: not a git repository (or any of the parent directories): .git.

Hm, ich glaube nicht, dass es mit dem Problem zusammenhängt. Der Befehl git clone git@github.com:UnlyEd/serverless-plugin-dynamodb-backups.git, der kein Verzeichnis angibt, erstellt standardmäßig eines. Und es ist durchaus möglich, ein Git-Repo aus einem anderen Git-Repo heraus zu klonen :)
Bei beidem hast du recht. Mein Zweifel ist, dass ein übergeordnetes Git-Repo einen Fehler hat, der dieses Problem verursacht. Wie auch immer, dies sind nicht die Probleme, die Sie haben.
Git-Klon schlägt mit „fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed“ unter MacOS Mojave fehl
AntwortenHierDatenschutz-Bestimmungen1y, 0v