Ich habe Verzeichnis A mit Dateien, die mit Verzeichnis B übereinstimmen. Verzeichnis A enthält möglicherweise andere benötigte Dateien. Verzeichnis B ist ein Git-Repo.
Ich möchte Verzeichnis B in Verzeichnis A klonen, aber git-clone erlaubt mir das nicht, da das Verzeichnis nicht leer ist.
Ich hatte gehofft, es würde nur .git klonen und da alle Dateien übereinstimmen, könnte ich von dort aus gehen?
Ich kann nicht in ein leeres Verzeichnis klonen, weil ich Dateien in Verzeichnis A habe, die nicht in Verzeichnis B sind, und ich sie behalten möchte.
Das Kopieren von .git ist keine Option, da ich Refs zum Push/Pull verwenden möchte und sie nicht manuell einrichten möchte.
Gibt es eine Möglichkeit, dies zu tun?
Update: Ich denke, das funktioniert, kann jemand irgendwelche Probleme sehen? –>
cd a
git clone --no-hardlinks --no-checkout ../b a.tmp
mv a.tmp/.git .
rm -rf a.tmp
git unstage # apparently git thinks all the files are deleted if you don't do this
Ich frage mich nur, was passieren würde, wenn ‘–no-checkout’ weggelassen würde, außer dass der temporäre Klon mehr Speicherplatz und Zeit verbraucht. Wäre ‘git unstage’ oder etwas anderes noch nötig?
git init
git remote add origin PATH/TO/REPO
git fetch
git reset origin/master # Required when the versioned files existed in path before "git init" of this repo.
git checkout -t origin/master
HINWEIS:-t wird den Upstream-Zweig für Sie festlegen, wenn Sie dies wünschen, und das ist normalerweise der Fall.
Dies funktioniert nicht in einem nicht leeren Verzeichnis, wenn die eingehenden Dateien bereits vorhanden sind (wie in der ursprünglichen Frage beschrieben). Aber wenn du git reset origin/master nach dem git fetchwird es funktionieren (und alle lokalen Änderungen beibehalten).
– Araxie
15. August 2014 um 0:42 Uhr
fatal: Pfade können nicht aktualisiert und gleichzeitig zum Zweig ‘Master’ gewechselt werden.
– Arnold Roa
19. April 2015 um 23:43 Uhr
Diese Antwort funktioniert bei mir nicht. Wenn ich es tue git checkout ... git beschwert sich, dass alle meine Dateien überschrieben würden und ich sie zuerst verschieben sollte. Wenn ich zuerst ` git reset origin/master/` mache, beschwert sich der Checkout-Befehl, dass ein Branch namens master bereits existiert.
– Saskia
20. Oktober 2016 um 17:16 Uhr
git checkout master war ein ausreichender letzter Schritt für mich.
– Jojo
11. Januar 2017 um 1:40 Uhr
Alle Schritte haben perfekt funktioniert, aber der letzte hat mich erwischt: fatal: A branch named 'master' already exists. Ich glaube, ich habe es nicht wirklich gebraucht.
– Schadi
20. Oktober 2017 um 11:45 Uhr
Dale Förster
In den folgenden Shell-Befehlen existing-dir ist ein Verzeichnis, dessen Inhalt mit den nachverfolgten Dateien in der übereinstimmt repo-to-clone Git-Repository.
# Clone just the repository's .git folder (excluding files as they are already in
# `existing-dir`) into an empty temporary directory
git clone --no-checkout repo-to-clone existing-dir/existing-dir.tmp # might want --no-hardlinks for cloning local repo
# Move the .git folder to the directory with the files.
# This makes `existing-dir` a git repo.
mv existing-dir/existing-dir.tmp/.git existing-dir/
# Delete the temporary directory
rmdir existing-dir/existing-dir.tmp
cd existing-dir
# git thinks all files are deleted, this reverts the state of the repo to HEAD.
# WARNING: any local changes to the files will be lost.
git reset --hard HEAD
Ich musste tun git reset --hard HEAD oder es würde die “gelöschten” Dateien nicht aufgeben.
– Dimitar
31. August 2011 um 18:25 Uhr
git reset HEAD hat bei mir gut funktioniert. git reset --hard HEAD zerstört alle Änderungen in Ihren Dateien, wenn sie also nicht genau mit den Dateien im Repository übereinstimmen, sollten Sie dies nicht tun.
– Tgr
19. Dezember 2012 um 16:58 Uhr
git reset HEAD scheint bei mir keinen Einfluss zu haben. git reset --hard HEAD tut – aber dadurch gehen alle Änderungen verloren, die Sie an den Dateien vorgenommen haben. Gibt es eine bessere Lösung?
– Jacob Dormann
20. Juli 2013 um 1:14 Uhr
@Caseys Antwort – git init/remote add/fetch/checkout – ist sauberer und einfacher und erfordert keine temporären Ordner.
– Jojo
25. Juli 2014 um 21:03 Uhr
Die Antwort von @Casey hat bei mir nicht funktioniert, als es bereits Dateien in Ordnern gab, die verbleiben mussten, sich aber nicht im Git-Repo befanden. Dies ist nützlich, um die Konfiguration nach dem Ausführen von Installationsskripten zu aktualisieren, bei denen Dateien und Verzeichnisse erstellt werden, aber Sie Dateien zusätzlich zu den installierten Elementen aktualisieren/hinzufügen müssen.
– Seelenstein
4. August 2014 um 15:58 Uhr
mohsaied
Eine leichte Änderung an einer der Antworten, die für mich funktioniert hat:
sofort mit der Arbeit am Master-Zweig zu beginnen.
musste HEAD –hard zurücksetzen, um das schmutzige vorhandene Verzeichnis zu bereinigen, ohne irrelevante Dateien zu entfernen, die in gitignore angegeben sind
– Ray Foss
28. Juni 2017 um 17:25 Uhr
Dies ist diejenige, die tatsächlich für mich funktioniert hat, im Gegensatz zur Antwort von @cmcginty.
– sicherlich akey
7. September 2017 um 6:18 Uhr
Dies ist nicht ganz gleichbedeutend mit einem Git-Clone – was fehlt, sind die Upstream-Informationen für den Master-Branch. Dies kann durch Hinzufügen behoben werden git branch --set-upstream-to=origin/master master.
– Slaven Rezic
20. April 2018 um 13:46 Uhr
Diese Version hat bei mir funktioniert, musste nur einen Git-Reset durchführen –hard HEAD
– Frédéric Klee
17. September 2019 um 15:11 Uhr
JohnFF
Warnung – dies könnte möglicherweise Dateien überschreiben.
Geändert von @cmcgintys Antwort – ohne das -f hat es bei mir nicht funktioniert
Björn Snoen
Folgendes habe ich letztendlich getan, als ich das gleiche Problem hatte (zumindest denke ich, dass es das gleiche Problem ist). Ich ging in Verzeichnis A und rannte git init.
Da ich nicht wollte, dass den Dateien in Verzeichnis A git folgt, habe ich .gitignore bearbeitet und die vorhandenen Dateien hinzugefügt. Danach bin ich gerannt git remote add origin '<url>' && git pull origin master et voíla, B wird ohne einen einzigen Schluckauf in A “geklont”.
Diese Technik funktioniert nicht in einem nicht leeren Verzeichnis, wenn die eingehenden Dateien bereits vorhanden sind (wie in der ursprünglichen Frage beschrieben).
– Araxie
15. August 2014 um 0:49 Uhr
Ich habe dies vor ein paar Augenblicken verwendet, erfordert die am wenigsten potenziell destruktiven Befehle:
Diese Technik funktioniert nicht in einem nicht leeren Verzeichnis, wenn die eingehenden Dateien bereits vorhanden sind (wie in der ursprünglichen Frage beschrieben).
– Araxie
15. August 2014 um 0:49 Uhr
Ken Williams
Ein anderes einfaches Rezept scheint für mich gut zu funktionieren:
Mein Hauptanwendungsfall für das Auschecken in ein Verzeichnis mit vorhandenen Dateien ist die Steuerung meiner Unix-Dotfiles mit Git. Bei einem neuen Konto enthält das Home-Verzeichnis bereits einige Dateien, möglicherweise sogar die, die ich von Git erhalten möchte.
Bare-Repositorys sind etwas anders eingerichtet, und obwohl dies funktioniert, würde ich es nicht empfehlen. 🙂
– ThorSummoner
17. Februar 2016 um 23:54 Uhr
Kannst du genauer sein? Was ist anders?
– Ken Williams
18. Februar 2016 um 2:02 Uhr
Nur zwei Unterschiede: 1.) Die .git/config Datei zeigt an, dass das Repos leer ist. 2.) Dateien normalerweise gespeichert in .git wird im Stammverzeichnis gespeichert (das Sie aufgerufen haben .git)
– mozy
1. Februar 2017 um 16:00 Uhr
Das sind genau die Änderungen, die das Klonen bewirkt .git und Einstellung core.bare zu false kümmern, also fühle ich mich immer noch gut mit dieser Methode.
– Ken Williams
18. Mai 2017 um 22:12 Uhr
9836100cookie-checkWie klone ich in ein nicht leeres Verzeichnis?yes
Ich frage mich nur, was passieren würde, wenn ‘–no-checkout’ weggelassen würde, außer dass der temporäre Klon mehr Speicherplatz und Zeit verbraucht. Wäre ‘git unstage’ oder etwas anderes noch nötig?
– Grenix
25. Mai 2021 um 15:09 Uhr
Vielleicht git-force-clone?
– Wunderkerze
29. September 2021 um 4:51 Uhr