Ich bin neu bei Git und habe eine ziemlich große Anzahl von wöchentlichen Tarballs aus einem lang laufenden Projekt. Jeder Tarball hat durchschnittlich ein paar hundert Dateien. Ich bin auf der Suche nach einer Git-Strategie, die es mir ermöglicht, den erweiterten Inhalt jedes Tarballs in ein neues Git-Repository aufzunehmen, beginnend mit Version 1.001 und bis Version 1.650. Ab diesem Stadium des Projekts sind 99,5% von Tarball (n) nur eine Kopie der Version (n-1) - mit anderen Worten, ein perfekter Kandidat für Git. Das gewünschte Endergebnis ist, dass nur der Master-Zweig am Ende des Prozesses übrig bleibt.
Ich denke, ich kenne git gut genug, um das "von Hand" zu machen. Wie ich es verstehe, gibt es keine Möglichkeit eines Merge-Konflikts, da es keine Möglichkeit gibt, den Master zu ändern, bevor die nächste Version hinzugefügt und festgeschrieben wird. Ein Shell-Skript ist meine erste Vermutung, aber ich bin mir nicht sicher, wie gut bash es mögen wird, wenn git checkout branch_n verarbeitet wird, während bash in branch_n-1 ausgeführt wird. Für die Zwecke dieses Projekts ist die Hostumgebung Ubuntu 10.4, verfügbare Ressourcen sind 8 Gig RAM, 500 Gigdisk Speicherplatz frei und 4 CPU-Prozessor bei 3.ghz.
Ich brauche keinen anderen, um das Problem zu lösen, aber ich könnte einen Anstoß in die richtige Richtung nehmen, wie ein Git-Experte es angehen würde. Jeder Rat von jemandem, der "dort gewesen ist", würde geschätzt werden.
Hotei
PS: Ich habe mir die "verwandten Fragen" der Seite angeschaut und nichts Relevantes gefunden.
In Bezug auf diesen Kommentar:
Ich bin nicht sicher, wie gut bash es mögen wird, wenn git checkout branch_n verarbeitet wird, während bash in branch_n-1 ausgeführt wird
Sind Sie besorgt darüber, dass zwei Operationen gleichzeitig ausgeführt werden und sich gegenseitig in die Quere kommen? Dies sollte kein Problem sein, wenn Sie nicht absichtlich Operationen parallel ausführen.
Unter der Annahme, dass die Tarballs einer linearen Evolution folgen, sollte die Verzweigung gar nicht dazu führen.
Der Prozess sollte ziemlich einfach sein:
git init untar ball _n_ git add --all .; git commit (mit entsprechenden Flags) git tag -a v1.001 -m "Version 1.001." rm -rf * (um Löschungen im Verlauf zu behandeln; Sie möchten natürlich .git intakt lassen) Schauen Sie sich $GIT_SRC_DIR/contrib/fast-import/import-tars.perl
Was ich in dieser Situation tun würde, da Sie Tarballs haben, die am Ende 'getaggte Versionen' sind:
git add .
git commit -a -m 'version foo' In Ihrem Fall ist es nicht notwendig, Zweige zu erstellen, da alle Ihre Tarballs verschiedene aufeinanderfolgende Versionen sind; Jede Iteration überschreibt die vorherige.
Ohne genau dort gewesen zu sein, solltest du einfach:
git add -A git commit -m "archive n" Die Idee besteht nicht darin, branch_n + 1 zu überprüfen, sondern im selben Zweig zu bleiben und jeden Teer-Inhalt nacheinander in derselben Verzweigung desselben Git-Repos zu speichern.
Sollten Sie wirklich zwei gleichzeitige Prozesse haben, könnten Sie dann:
git clone der erste Git Repo git branch -b a_new_branch , um sicherzustellen, dass Sie diesen parallelen Prozess in seinem eigenen Zweig isolieren, den Sie nach Abschluss des Vorgangs in den ersten Repo zurückschieben können. Tags und Links git