2016-06-07 15 views
0

Ich beginne mit Git. Ich habe ein Repo paraphiert und zuerst Commits gemacht. Um mit einem Freund zu arbeiten, klonte ich mein ursprüngliches Repository (mit --bare) an einen zugänglichen Ort und begann mit ihm an dieser Kopie zu arbeiten. So werden unsere beiden Arbeitskopien vom späteren geklont. Irgendwann habe ich entschieden, dass ich das Original-Repo nicht mehr brauche und es gelöscht habe. Und nun zeigen unsere beiden Arbeitskopien alle möglichen Fehler mit defekten Links/Objekten/Baum, da immer noch ein Verweis auf den alten Ort/Pfad des ursprünglichen Repos vorhanden ist. Wo finde ich das oder bereinige den Code? Eine Erklärung, wie das passiert ist, wäre nett. Nach unserem Verständnis sind alle Git-Instanzen unabhängig und enthalten den kompletten Baum. (Das war der Punkt der Verwendung von Git).git Vererbung alten Pfad

Danke für Ihre Hilfe. Phil

ps. .: Ich entfernte den Verweis auf das alte Repository von der nackten durch Bearbeiten von .git/config vor dem Klonen.

edit:

[email protected]:/work1/user/code/NIRVANA/TITVS> git remote -v 
    origin /work1/user/TITVS.git/ (fetch)      #edit:this is the new repo 
    origin /work1/user/TITVS.git/ (push)      #edit:this is the new repo 
    [email protected]:/work1/user/code/NIRVANA/TITVS> git pull 
    error: object directory /work1/user/TITVS/.git/objects does not exist; check .git/objects/info/alternates. #edit:this is the OLD repo 
    error: refs/remotes/origin/cleanning does not point to a valid object! 
    error: refs/remotes/origin/phil_test does not point to a valid object! 
    error: refs/remotes/origin/test does not point to a valid object! 
    error: refs/remotes/origin/test2 does not point to a valid object! 
    error: refs/tags/0.2.0 does not point to a valid object! 
    error: object directory /work1/user/TITVS/.git/objects does not exist; check .git/objects/info/alternates. 
    error: refs/heads/cleanning does not point to a valid object! 
    error: refs/heads/phil_test does not point to a valid object! 
    error: refs/heads/test does not point to a valid object! 
    error: refs/heads/test2 does not point to a valid object! 
    error: refs/tags/0.2.0 does not point to a valid object! 
    error: refs/remotes/origin/cleanning does not point to a valid object! 
    error: refs/remotes/origin/phil_test does not point to a valid object! 
    error: refs/remotes/origin/test does not point to a valid object! 
    error: refs/remotes/origin/test2 does not point to a valid object! 
    error: refs/tags/0.2.0 does not point to a valid object! 
    error: object directory /work1/user/TITVS/.git/objects does not exist; check .git/objects/info/alternates. 
    error: refs/remotes/origin/cleanning does not point to a valid object! 
    error: refs/remotes/origin/phil_test does not point to a valid object! 
    error: refs/remotes/origin/test does not point to a valid object! 
    error: refs/remotes/origin/test2 does not point to a valid object! 
    error: refs/tags/0.2.0 does not point to a valid object! 
    error: refs/remotes/origin/cleanning does not point to a valid object! 
    error: refs/remotes/origin/phil_test does not point to a valid object! 
    error: refs/remotes/origin/test does not point to a valid object! 
    error: refs/remotes/origin/test2 does not point to a valid object! 
    error: refs/tags/0.2.0 does not point to a valid object! 
    error: object directory /work1/user/TITVS/.git/objects does not exist; check .git/objects/info/alternates. 
    error: object directory /work1/user/TITVS/.git/objects does not exist; check .git/objects/info/alternates. 
    error: object directory /work1/user/TITVS/.git/objects does not exist; check .git/objects/info/alternates. 
    Already up-to-date. 
+0

Können Sie uns Ihre Fehler zeigen? – FrenchieTucker

+0

Bitte geben Sie ein konkretes Beispiel für eine Fehlermeldung, die Sie erhalten. Wenn Sie --shared beim Einrichten Ihrer Klone verwenden, hat das Löschen des ursprünglichen Repositorys möglicherweise alle Ihre Objekte zerstört. – antlersoft

+0

@antlersoft Tanks für den Rat. Ich habe meine Änderungen rückgängig gemacht und konfiguriert und die folgenden Befehle verwendet, um den Repo zu löschen, aber das Problem ist das gleiche. Beide Repos (alt und neu) wurden geteilt. – user544726

Antwort

0

Wenn Sie ein Repository mit -shared klonen und dann das ursprüngliche Repository löschen, haben Sie kein Glück; Sie können die Klone nur wiederherstellen, indem Sie das Original aus der Sicherung wiederherstellen.

Die Moral der Geschichte: Verwenden Sie nicht "-shared" beim Klonen eines Repository (die einzige Zeit, um es zu verwenden ist, wenn Ihr Repository einen großen Teil Ihres gesamten Speicherplatzes belegt, was eine seltene Situation ist heutzutage).

aus dem git manpage zu zitieren:

ist dies eine möglicherweise gefährliche Operation; Verwenden Sie es nicht, es sei denn Sie verstehen, was es tut. Wenn Sie Ihr Repository mit dieser Option klonen und dann Zweige löschen (oder einen anderen Git-Befehl verwenden, der ein vorhandenes Commit nicht referenziert) im Repository der Quelle , können einige Objekte nicht referenziert werden (oder hängen). Diese Objekte können durch normale Git-Operationen (z. B. Git commit) entfernt werden, die automatisch git gc --auto aufrufen. (Siehe git-gc (1).) Wenn diese Objekte entfernt und vom geklonten -Repository referenziert werden, wird das geklonte Repository beschädigt.

+0

Ok ... danke für das Heads-Up. Gibt es eine Möglichkeit, das neue Repository von der Referenz auf die alte zu säubern - wenn man sich nicht um die frühen Commits kümmert (sie sind eigentlich nicht so viele)? – user544726

+0

@ user544726 - Was Sie wahrscheinlich tun müssen, ist rm -rf der .git-Ordner für Ihr Repository in Ihrem bevorzugten nicht-blanken Quellbaum. (nur der .git-Ordner!) - dann ist dein Source-Tree nicht mehr an Git gebunden. Dann verhalten Sie sich so, als würden Sie ein neues Git-Repository für eine vorhandene Codebasis starten: Führen Sie git init im obersten Ordner aus; Git hinzufügen.; git commit. Da Sie zwei verschiedene Repositories mit diesem Problem haben, müssen Sie dies in beiden Fällen tun. Um dann die beiden Repositories zu synchronisieren, können Sie eins als das Remote des anderen festlegen und einen Pull durchführen. – antlersoft

+0

[email protected] Einfach neu anzufangen ist jedoch keine wirkliche Lösung für mich. Ich hatte mehr auf Hilfe in Richtung der Links unten gehofft. Ich denke, es sollte möglich sein, den Repo zu reinigen. Allerdings lohnt es sich nicht mehr nach einer Lösung für mein kleines Repo zu suchen. Leute mit ähnlichen Problemen können hier nachschauen: https://rewoo.wordpress.com/2012/02/14/recover-a-corrupt-git-bare-repository/ oder suche nach "git tree neu aufbauen" oder "beschädigte repository wiederherstellen" . Hat aber nicht für mich gearbeitet ... – user544726

0

Sie sollten nur kopieren bare Repository, wenn Sie das Arbeitsverzeichnis nicht brauchen. Sie sollten auch nichts im .git-Verzeichnis bearbeiten, es ist nicht sicher.

Um Remote zu ändern Sie diese Befehle verwenden können:

  1. git remote -v zeigt Liste aller konfigurierten Fernbedienungen
  2. git remote rm [name] von [name] remote angegeben Entfernt
  3. git remote add [name] [path] fügt Fernbedienung mit [name] und Ort [ Pfad], können Sie den Namen verwenden, zum Beispiel: git push [name] [branchname]
  4. git remote set-url [name] [newurl] Updates remote von [Name] mit neuer URL
  5. angegeben