Repositories zusammenführen
Meine Daten, unter anderem den Schriftverkehr, meine Präsentationen und kleinen Skripte, verwalte ich in Git-Repositories (Mehrzahl). Nach längerer Diskussion bin ich zu der Einsicht gekommen, dass es sinnvoller ist, alles in einem einzigen Repository zu haben.
Natürlich möchte ich dabei die Historie nicht verlieren.
Der folgende Weg löst den Import für mich.
Ergänzungen von Euch sind mir jederzeit willkommen.
Im Source-Repository (ausgescheckt nach presentations.git):
$ cd presentations.git
$ tomove=$(ls -1a | egrep -v '^(.|..|.git)$' | xargs)
$ mkdir presentations
$ git mv $tomove presentations
$ git commit -am "Vorbereitung für den Merge"
$ git push
$ cd ..
Im Destination-Repository (ausgecheckt in main.git):
$ cd main.git
$ git remote add -f presentations URL/presentations.git
$ git merge --allow-unrelated-histories presentations/master
$ git push
$ git remote remove presentations
Trackbacks
Dirks Logbuch am : Wie ich Ende 2021 arbeite (Client)
Vorschau anzeigen
Was soll ich als Einleitung schreiben, auch hier gab es einen Artikel im letzten Jahr? Hier hat sich ebenfalls viel mehr getan als auf der Serverseite. Hardware Nach längerer Zeit, in der ich mir nur Notebooks gekauft habe, verrichtet nun ein n
Dirks Logbuch am : Linkdump 52/2021
Vorschau anzeigen
Jetzt ist er da, der letzte Linkdump 2021. Ich hatte zwar ausreichend Artikel, aber die meisten waren so alt, dass sie nicht mehr auf ihren Webseiten verfügbar waren. Daher bekommt Ihr jetzt einen aktuellen Artikel, den ich sehr gut finde und eine kleine
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
tux. am :
Meinjanur.
Dirk Deimeke am :
SCCS kenne ich nicht.
Beim Verschieben der Dateien bleibt die Historie auf der Strecke. Wenn man schon Versionskontrolle einsetzt, dann sollte die doch erhalten bleiben.
tux. am :
SCCS ist das Standard-POSIX-Versionskontrollsystem. Ein bisschen Technik hatte ich dazu mal hier erklärt:
https://dev.to/tux0r/tired-of-jira-here-s-a-pure-posix-to-do-environment-versioned-and-awesome-or-a-case-for-sccs-3pfa
Für einzelne Dateien ist es deutlich besser geeignet als Git, Mercurial und sogar Darcs. Das hatte ich mal verglichen:
https://gist.github.com/dertuxmalwieder/1890c954d96389d97c2653da08556c15
Aber ich erwarte natürlich nicht, dass so was außer mir irgendwer mag.
Dirk Deimeke am :
Klingt spannend. Danke für die Links!
tux. am :
Dirk Deimeke am :
Paul am :
Wäre für mich wirklich interessant, was dich letztendlich überzeugt hat, das alles in ein "großes" Repo zu packen. Magst du das vielleicht nochmal etwas genauer erläutern?
Ich habe nämlich im Grunde genau das gleiche Konzept. Lebenslauf, Präsentationen, Vorlagen, Projekte liegen bei mir alle in Git Repos. Allerdings schön aufgeteilt, jedes in seinem eigenen Projekt. Ich habe zusätzliche Gruppen mit entsprechendem Namen, z.B. "presentations" und darin dann einzelne Projekte. Hinzu kommt, dass ich vor allem die Latex "Projekte" direkt über eine CI kompilieren lasse und das PDF im Projekt herunterladen kann (ich wollte es nicht ins Projekt einchecken, sondern nur den Quellcode).
Welchen Vorteil hat es denn, das alles in einem Repo zu haben?
Gruß
Paul
Dirk Deimeke am :
Welchen Grund kann man umgekehrt haben, verschiedene Repos zu verwenden?
Ursprüngliche Idee, um es sauber getrennt zu haben - ein Verzeichnis in einem grösseren Repo ist auch eine saubere Trennung. Vor allem, wenn alle Teilrepositories auf den gleichen Maschinen ausgecheckt sind.
Ein Vorteil von einem Repo ist, dass man Daten aus einem Teil des Repos in einem anderen Teil des Repos weiterverwenden kann (Lebenslauf -> Präsentationen).
Ich werde auch nach dem Move noch unterschiedliche Repos haben, je nach Anwendungsfall, aber es werden deutlich weniger sein.
silvio grau am :
ich hätte ja git subtree verwendet.
in deinem Fall in etwa so:
und dannach einen cleanup bezüglich buildscripts etc ...
Naja, so ungefähr.
So nebenbei: Der folgenden Part hätte man doch eigentlich mit einem
$ mkdir presentations
$ git mv $tomove presentations
Oder sehe ich etwas nicht?
Grüßle!
Silvio
Dirk Deimeke am :
Das Ursprungsrepository wird ja anschliessend vom Git-Server gelöscht. Die Historie soll ja komplett im Hauptrepository liegen.
Abkürzen lässt sich das Kommando nicht, zum einen erfasst Du keine Dateien, die mit einem Punkt anfangen und zum anderen versuchst Du ein Verzeichnis in sich selber zu verschieben.
Bei Deiner Variante ist ja "presentations" im "Stern" enthalten.
silvio grau am :
Das mit dem Subtree wollte ich genau nicht.
Das Ursprungsrepository wird ja anschliessend vom Git-Server gelöscht. Die Historie soll ja komplett im Hauptrepository liegen.
Subtree ist nicht submodule. subtrees machen das alles etwas anders. Die History wird mit in dem submodule übernommen. Viele beispiel von subtree verwenden dabei die option `--squash`, das willst du nicht. Dannach ist das repository und die Historie ein Teil der historie. Schau ...
Vorbereitung ...
~/gittest ⯠mkdir repo1 repo2
~/gittest ⯠cd repo2
~/gittest/repo2 ⯠git init
Initialized empty Git repository in /gittest/repo2/.git/
repo2 î‚ main ⯠echo "Inhalt von file2" > file2
repo2 î‚ main ⯠git add file2
repo2 î‚ main ⯠git commit -sm "ic: repo2"
[main (root-commit) c496016] ic: repo2
1 file changed, 1 insertion(+)
create mode 100644 file2
repo2 î‚ main ⯠cd ../repo1
~/gittest/repo1 ⯠git init
Initialized empty Git repository in /gittest/repo1/.git/
repo1 î‚ main ⯠echo "Inhalt von file1" > file1
repo1 î‚ main ⯠git add file1
repo1 î‚ main ⯠git commit -sm "ic: repo1"
[main (root-commit) 974c01d] ic: repo1
1 file changed, 1 insertion(+)
create mode 100644 file1
Und nun inkludiere ich das repo2, in das repo1, mittels subtree:
git fetch ../repo2/.git main
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 227 bytes | 227.00 KiB/s, done.
From ../repo2/
* branch main -> FETCH_HEAD
Added dir 'from_repo2'
repo1 î‚ main ⯠git log --graph --oneline
* e7a2a3c (HEAD -> main) Add 'from_repo2/' from commit 'c496016e9ecf048499e7d758b36d045c190a6a03'
|\
| * c496016 ic: repo2
* 974c01d ic: repo1
repo1 î‚ main ⯠git show e7a2a3c
commit e7a2a3c5285a8021a3750ceaea21f52aa6e4b9ad (HEAD -> main)
Merge: 974c01d c496016
Author: Silvio Grau
Date: Thu Mar 25 15:04:22 2021 +0100
Add 'from_repo2/' from commit 'c496016e9ecf048499e7d758b36d045c190a6a03'
git-subtree-dir: from_repo2
git-subtree-mainline: 974c01d6d14f3e42619cedcaef167b9e101ddafb
git-subtree-split: c496016e9ecf048499e7d758b36d045c190a6a03
diff --cc from_repo2/file2
index 0000000,692f47e..692f47e
mode 000000,100644..100644
--- a/from_repo2/file2
+++ b/from_repo2/file2
repo1 î‚ main ⯠ls -al
total 20
drwxr-xr-x 4 sfr sfr 4096 Mar 25 15:04 .
drwxr-xr-x 4 sfr sfr 4096 Mar 25 14:58 ..
-rw-r--r-- 1 sfr sfr 17 Mar 25 14:59 file1
drwxr-xr-x 2 sfr sfr 4096 Mar 25 15:04 from_repo2
drwxr-xr-x 9 sfr sfr 4096 Mar 25 15:04 .git
repo1 î‚ main ⯠cat from_repo2/file2
Inhalt von file2
Zum anderen Beispiel hatte ich bei mir die Optionen `fk` vergessen. Aber auch das geht:
repo2 î‚ main ⯠git status
On branch main
Changes to be committed:
(use "git restore --staged ..." to unstage)
renamed: file2 -> presentation/file2
* Iwie komm ich mit bbcode nicht klar!
Sorry
Dirk Deimeke am :
Was ich nicht verstehe, ist, wo der Vorteil von Subtreee gegenüber dem Merge liegen soll.
silvio grau am :
Wollte es ja nur erwähnt haben!
Dirk Deimeke am :
Wenn ich das nächste Mal eine solche Aktion starten muss, probiere ich Deinen Weg auch einmal aus.