Remote abgelehnt (flaches Update nicht erlaubt) nach Änderung der Git-Remote-URL

163

Ich habe ein Projekt unter Git-Versionskontrolle, das ich sowohl auf einem Server als auch auf meinem lokalen Computer bearbeitet habe. Ich hatte ursprünglich den Remote-Ursprung als meinen lokalen Computer festgelegt, möchte diesen nun aber in BitBucket ändern.

Auf dem Server habe ich den Befehl verwendet

git remote set-url origin bitbucket_address

Aber jetzt, wenn ich versuche, mein Projekt voranzutreiben, erhalte ich den Fehler

 ! [remote rejected] master -> master (shallow update not allowed)

Was verursacht das und wie behebe ich es?

git

— rwolst
quelle

3

Wie haben Sie Ihre lokale Version geklont? git clone --depth?

— Sascha Wolf

Es ist eine Weile her und ich kann mich nicht erinnern. Gibt es einen Weg, das herauszufinden?

— rwolst

2

shallowIn Ihrem .gitOrdner sollte sich eine Datei mit dem Namen befinden .

— Sascha Wolf

Ja, ich kann eine shallowDatei sehen.

— rwolst

Unter stackoverflow.com/a/50996201 finden Sie eine Lösung, die nur den fehlenden Verlauf verwirft (oder neu schreibt)

— caw

328

Wie es scheint, haben Sie git clone --depth <number>Ihre lokale Version geklont. Dies führt zu einem flachen Klon . Eine Einschränkung eines solchen Klons besteht darin, dass Sie ihn nicht in ein neues Repository verschieben können.

Sie haben jetzt zwei Möglichkeiten:

Wenn Sie sich nicht für Ihre aktuelle oder fehlende Geschichte interessieren, werfen Sie einen Blick auf diese Frage
Wenn Sie Ihre vollständige Historie behalten möchten, lesen Sie weiter:

Also, du willst deine Geschichte behalten, was? Dies bedeutet, dass Sie Ihr Repository deaktivieren müssen . Dazu müssen Sie Ihre alte Fernbedienung erneut hinzufügen.

git remote add old <path-to-old-remote>

Danach rufen wir git fetchden verbleibenden Verlauf von der alten Fernbedienung ab (wie in dieser Antwort vorgeschlagen ).

git fetch --unshallow old

Und jetzt sollten Sie in der Lage sein, in Ihr neues Remote-Repository zu pushen.

Hinweis : Nachdem Sie Ihren Klon deaktiviert haben, können Sie die alte Fernbedienung offensichtlich wieder entfernen.

— Sascha Wolf
quelle

45

Was ist, wenn ich ein Kick-Start-Projekt geklont habe und nicht die ganze Geschichte will / brauche? Gibt es eine Möglichkeit, dies zu vermeiden?

— Itamar

9

@itamar Dies scheint ein gutes Beispiel für eine vollkommen gültige neue Frage zu sein. Sie können als Referenz auf diese Frage verlinken.

— Sascha Wolf

14

Als neue Frage gestellt stackoverflow.com/questions/29748197/…

— itamar

2

Beachten Sie, dass git fetch --unshalloweine Referenzspezifikation erforderlich sein kann, um nur einen bestimmten Zweig und nicht das gesamte Repo aufzuheben. ZB:git fetch --unshallow origin refs/heads/mydeepbranch:refs/remotes/origin/mydeepbranch

— Clacke

5

Wenn Sie zu einem Repo wechseln, das etwas hinter dem Repo liegt, aus dem Sie geklont haben, und kein brandneues Repo erstellen, reicht es aus, dass Ihre lokale Referenz tief genug ist, um die Remote-Referenz aufzunehmen. Also , wenn Ihr origin/masterwar 20 Commits vor Ihrer , oldrepo/masterwenn Sie clone --depth 1‚es ed, und Sie haben 17 lokale Commits gemacht , da es genug ist für Sie zu tun git fetch --depth 37 origin refs/heads/master:refs/remotes/origin/master(entschuldigen uns für die Off-by-one - Fehler), und dann können Sie tun , git push oldrepo masterohne Zwischenfälle (Möglicherweise ist Git 1.9.0 oder neuer erforderlich).

— Clacke

27

Falls Ihr Repo ist originund das ursprüngliche Repo ist upstream:

git fetch --unshallow upstream

— Dorian
quelle

Das funktioniert bei mir und ist ganz einfach, dann die am besten gewählte Antwort.

— Maosheng Wang

11

Eine weitere Option, wenn Sie das Repo wie bei den neuen Commits beibehalten möchten, die Sie seit dem flachen anfänglichen Commit hinzugefügt haben, ist folgende: Ändern Sie dieses Commit mit einer interaktiven Rebase .

Starten Sie eine interaktive Rebase einschließlich des ersten (Root-) Commits mit
```
git rebase --interactive --root
```
Ändern Sie die pickursprünglichen Commits in editund speichern und schließen Sie die Datei.

Wenn Sie das Repo mit einer Tiefe von mehr als 1 geklont haben, müssen Sie möglicherweise für alle diese Commits dasselbe tun. Oder führen Sie alternativ fixupfür alle diese während der interaktiven Rebase aus.
Konvertieren Sie dieses Commit in ein reguläres, nicht heiliges Commit mit
```
git commit --amend --no-edit
```
Dadurch wird auch die Festschreibungs-ID geändert und Sie werden als Co-Autor zu dieser anfänglichen Festschreibung hinzugefügt.
Vergiss nicht, deine Rebase zu beenden
```
git rebase --continue
```

— Rene Hamburger
quelle

Danke dir! Hat wie ein Zauber funktioniert, als das ursprüngliche Repository gelöscht wurde und Sie nur eine flache Kopie davon haben.

— Vitalii Dmitriev

9

Wenn Sie das neue Repo so wie es ist pushen möchten, können Sie Folgendes versuchen:

Entfernen Sie zuerst das old git folderaus Ihrem aktuellen Repo,sudo rm -rf .git
Dann initialisiere den Git erneut git init
Fügen Sie dann das neue Remote-Repo hinzu git remote add your-new-repo
Dann schieben Sie es.

— Akhter-uz-zaman
quelle

Ich fand das eine bessere Lösung, da es keinen Push zum alten erfordert. Manchmal kann dies mit Boilerplates passieren.

— rnpd

Dies ist im Grunde die Antwort auf die verwandte Frage, die Sie hier finden .

— Sascha Wolf

@NachPD Ich bin mir nicht sicher, was du meinst, wenn du sagst, dass die andere Lösung "einen Push to the Old" erfordert. Meinen Sie einen Abruf anstelle eines Pushs? Weil es keinen Push erfordert.

— Sascha Wolf

0

Wenn das Abrufen von --unshallow nicht funktioniert. Es muss einige Probleme mit Ihrer Niederlassung geben. Korrigieren Sie es mit dem folgenden Befehl, bevor Sie es drücken.

git filter-branch -- --all

Tun Sie dies nur mit --unshallow nicht da funktioniert es eine ist SAFETY Sorge.

— Chayapol
quelle