Repositories zusammenführen

Geschrieben von Dirk Deimeke am Mittwoch, 24. März 2021

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

Trackback-URL für diesen Eintrag

Dirks Logbuch am Donnerstag, 30. Dezember 2021: 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 Freitag, 31. Dezember 2021: 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 Mittwoch, 24. März 2021:

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 Mittwoch, 24. März 2021:

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 Mittwoch, 24. März 2021:

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 Mittwoch, 24. März 2021:

Davon habe ich wirklich noch nichts gehört.

Klingt spannend. Danke für die Links!

tux. am Mittwoch, 24. März 2021:

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

Dirk Deimeke am Mittwoch, 24. März 2021:

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

Paul am Mittwoch, 24. März 2021:

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 Mittwoch, 24. März 2021:

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 Donnerstag, 25. März 2021:

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 Donnerstag, 25. März 2021:

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 Donnerstag, 25. März 2021:

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 Donnerstag, 25. März 2021:

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 Donnerstag, 25. März 2021:

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!