Skip to content

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

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

tux. am :

*Mit SCCS - Präsentationen, Scripts usw. sind ja in der Regel bestenfalls einzelne Dateien - wäre das ein Befehl gewesen - nämlich "verschiebe alle Dateien in einen einzigen Ordner".

Meinjanur.

Dirk Deimeke am :

*Präsentationen in LaTeX bestehen aus dem Quellfile (*.tex) und Mediendateien, die eingebettet sind. Nach der Übersetzung fällt ein PDF raus.

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 verwaltet seine gesamte Historie in einer Datei (also einer Datei pro versionskontrollierter Datei, zum Beispiel s.meinedatei.tex für eine meinedatei.tex). Deswegen meinte ich: einfach (rekursiv) verschieben, Problem gelöst... ;-)

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 :

*Davon habe ich wirklich noch nichts gehört.

Klingt spannend. Danke für die Links!

tux. am :

*Gerne. Vielleicht kommt es ja mal bei dir zum Einsatz.

Dirk Deimeke am :

*Ich habe gerade keinen Anwendungsfall dafür, behalte das aber mal im Hinterkopf, für den "Fall der Fälle".

Paul am :

*Hallo Dirk,

QUOTE:
Nach längerer Diskussion bin ich zu der Einsicht gekommen, dass es sinnvoller ist, alles in einem einzigen Repository zu haben.


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 :

*Du musst nur eine Woche auf die nächste Episode des TILpod warten, da sprechen Sujeevan und ich darüber. Dem möchte ich nicht vorgreifen.

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 :

*hi Dirk,

ich hätte ja git subtree verwendet.

in deinem Fall in etwa so:

CODE:
git subtree add -P presentations URL/presentations.git


und dannach einen cleanup bezüglich buildscripts etc ...

Naja, so ungefähr.


So nebenbei: Der folgenden Part hätte man doch eigentlich mit einem
CODE:
mkdir presentations; git mv * presentations 
abkürzen können, oder?

CODE:
$ tomove=$(ls -1a | egrep -v '^(.|..|.git)$' | xargs)
$ mkdir presentations
$ git mv $tomove presentations


Oder sehe ich etwas nicht?

Grüßle!
Silvio

Dirk Deimeke 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.

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 :

*Hi,

QUOTE Dirk:

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 ...
CODE:
~ â¯ mkdircd gittest
~/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:

CODE:
repo1 î‚  main â¯ git subtree add -P from_repo2 ../repo2/.git main 
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:

CODE:
repo2 î‚  main took 2s â¯ git mv -fk * presentation
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 :

*BBCode ist ja dafür auch gar nicht gedacht.

Was ich nicht verstehe, ist, wo der Vorteil von Subtreee gegenüber dem Merge liegen soll.

silvio grau am :

*Der Vorteil ist, dass du dir die Arbeit mit dem verschieben etc sparen kannst, das macht das subtree von alleine, indem du sagen kannst, welcher branch des 2.repos in welches Verzeichnis abgelegt werden kann, ohne umstandlich ein VZ anzulegen - neuen commit anlegen, etc. nur git subtree und das wars.

Wollte es ja nur erwähnt haben!

Dirk Deimeke am :

*Vielen Dank für die Erwähnung, Silvio!

Wenn ich das nächste Mal eine solche Aktion starten muss, probiere ich Deinen Weg auch einmal aus.

Kommentar schreiben

Gravatar, Favatar, Pavatar, Identica, Twitter, MyBlogLog Autoren-Bilder werden unterstützt.
BBCode-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
:'(  :-)  :-|  :-O  :-(  8-)  :-D  :-P  ;-) 
Formular-Optionen