Forum: PC-Programmierung mehrere GIT repos


von H. R. (hacker_r)


Lesenswert?

hi
wie geht man eigentlich um mit einem Projekt wo es mehrere git repos 
gibt.
Ich errinere mich an ein Projekt der aus knapp 40 einzelne repos 
bestand. es gab ein tcl script der bei einem release ein git Tag über 
alle repos gezogen hat.

und es gab ein script der alle repos entweder basierend auf ein tag, 
oder überall den top of the tree gecloned hat.

Schreibt man Heutzutage einen eigenen Script, oder gibt es da ein tool?
Subrepos kommen für mein usecase nicht in Frage.

Wie gehen gitlab/github/bitbucket mit der Thematik um.

Danke

: Verschoben durch Admin
von Gerd E. (robberknight)


Lesenswert?

H. R. schrieb:
> Schreibt man Heutzutage einen eigenen Script, oder gibt es da ein tool?
> Subrepos kommen für mein usecase nicht in Frage.

warum genau kommen subrepos nicht in Frage? Bitte beschreibe das Problem 
sauber und ausführlich genug: wenn man das Problem/Usecase versteht, 
kann man vielleicht passende Tools vorschlagen.

Mit Subrepos kannst Du zumindest die Sache mit dem zentralen Release-Tag 
sauber lösen.

> Wie gehen gitlab/github/bitbucket mit der Thematik um.

Mir wäre nicht bewusst daß die einen extra Workflow oder Tool für 
mehrere gemeinsame Repos, die aber keine subrepos sind, anbieten würden.

von Rolf M. (rmagnus)


Lesenswert?

Hmm, lass mich das mal zusammenfassen: Du hast in einem Projekt mehrere 
separate Repos, die zwar nichts mit einander zu tun haben und die auch 
nicht als "Subrepos"(*) ausgeführt werden sollen, aber trotzdem wie ein 
großes Repo behandelt werden sollen. Mir wäre dafür nichts bekannt, aber 
mir erschließt sich auch der Sinn nicht.

(*) Was ist damit gemeint? Submodules oder Subtrees? Oder beides?

von H. R. (hacker_r)


Lesenswert?

hi
also mein usecase:
es gibt 20 Produkte die verschiedene Versionen von irgendwelche 
Libraries/komponenten verwenden. Auf allen komponenten wirk aktive 
weiter gearbeitet.

Jedes Produkt hat ein eigenes Repo und ein TCL Script was alle Libraries 
und Ihre Versionen festlegt.

Ist das State of the Art?

von Le X. (lex_91)


Lesenswert?

H. R. schrieb:
> Ist das State of the Art?

Nein, Bastelskripte sind sicher nicht state of the art.

git bietet unter anderem das Feature "submodule" (was die oben erwähnten 
subrepos sein sollen weiß ich nicht, das gibts im git-Jargon nicht).
Mit submodule kannst du Dritt-Repos in dein Repo einbinden (und, ganz 
wichtig, auf einen spezifischen Commit referenzieren).
Da kannst du dich mal einlesen.
Ist aber ziemlich fummelig und fehleranfällig wenn man nicht weiß was 
man tut.
Aber besser als deine Skriptsammlung dürfts sein.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Android/AOSP macht das mit über 500 einzelnen Repositories, welche über 
ein Python-Programm "repo" verwaltet werden:
https://source.android.com/setup/develop/repo

von Vincent H. (vinci)


Lesenswert?

Ich check das gewünscht Szenario immer noch nicht. Ist es:

A) Ein Projekt besitzt Abhängigkeiten zu mehreren Bibliotheken 
(ebenfalls Projekte) und es geht darum diese zu verwalten und 
einzubinden.

B) Es existieren mehrere Projekte die nichts miteinander zu tun haben, 
die aber halt physikalisch am selben Git-Server liegen. Diese sollen 
verwaltet werden.

von imonbln (Gast)


Lesenswert?

Le X. schrieb:
>> Ist das State of the Art?
>
> Nein, Bastelskripte sind sicher nicht state of the art.

Na ja so Bastelskripte sind das nun wieder auch nicht, Wenn ich mir zum 
Beispiel das Yocto Projekt ansehe, dort werden git repos in den Rezepten 
auch über ihren Hashwert referenziert in den recipes.

Und das von dir präferierte git submodule ist eigentlich auch nur ein 
Referenzierter Hash in der .gitmodules mit ein paar convenience 
Funktionen.

H. R. schrieb:
> Ist das State of the Art?

Das Kommt drauf an ;) wenn dein TCL Script wirklich nur die 
entsprechenden SHA1-HASHs auscheckt vielleicht.

H. R. schrieb:
> TCL Script was alle Libraries
> und Ihre Versionen festlegt

Der Teil macht schon eher Zahnschmerzen, was genau heißt für dich "und 
Ihre Versionen festlegt" die Benötigen Versionen sollten ihrerseits in 
einen Git sein und nicht über irgenwelche Tags definiert werden und 
hierfür bringt das git Projekt halt den Mechanismus des submodule mit.

H. R. schrieb:
> es gibt 20 Produkte die verschiedene Versionen von irgendwelche
> Libraries/komponenten verwenden. Auf allen komponenten wirk aktive
> weiter gearbeitet.

Spätestens hier solltest du ganz laut Buildsystem schreien und nicht 
versuchen was selbst zu Bastelen, im Embedded Bereich ist gerade Yocto 
so eine art Industrie Standard. Aber es gibt auch noch ptxdist, 
e2factory Buildroot und viele andere, meine Empfehlung ist das du dich 
hier einarbeitetest und nicht versuchst das Rad neu zu erfinden.

von H. R. (hacker_r)


Lesenswert?

Vincent H. schrieb:
> Ich check das gewünscht Szenario immer noch nicht. Ist es:
>
> A) Ein Projekt besitzt Abhängigkeiten zu mehreren Bibliotheken
> (ebenfalls Projekte) und es geht darum diese zu verwalten und
> einzubinden.
>
variante A

von H. R. (hacker_r)


Lesenswert?

> Spätestens hier solltest du ganz laut Buildsystem schreien und nicht
> versuchen was selbst zu Bastelen, im Embedded Bereich ist gerade Yocto
> so eine art Industrie Standard. Aber es gibt auch noch ptxdist,
> e2factory Buildroot und viele andere, meine Empfehlung ist das du dich
> hier einarbeitetest und nicht versuchst das Rad neu zu erfinden.

Hi
Was YOCTO angeht: könntest du mir ein link zum git methodik in yocto 
schicken? ich sehe gerade das ist ein ziemlich grosses Projekt.
Oder wonach soll ich innerhalb von YOCTO suchen um drauf zu kommen wie 
da git verwendet wird?

von Vincent H. (vinci)


Lesenswert?

H. R. schrieb:
> variante A

Dafür verwend ich Git-Submodule.

: Bearbeitet durch User
von Bernd K. (prof7bit)


Lesenswert?

imonbln schrieb:
> im Embedded Bereich ist gerade Yocto
> so eine art Industrie Standard.

Yocto hat nur einen einzigen Zwweck: Ein bootbares Linux-Image nach 
eigenem Gusto mit eigenen Komponenten zu bauen, darum dreht sich 
99.9995% von dessen Funktionalität, yocto hat nichts damit zu tun 
irgendwelche git-Repositories besser zu managen als man es auch mit nem 
simplen Script machen könnte. Ganz im Gegenteil sogar, Yocto bringt 
praktisch gar nichts mit für sein git Problem, er wird noch mehr 
scripten müssen als er es jetzt schon tut.

Und anscheinend baut er keine Linux-Images sonst würde Yocto schon 
längst zu seinem Arsenal gehören, also hat er NULL Verwendung für Yocto.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Niklas G. schrieb:
> Android/AOSP macht das mit über 500 einzelnen Repositories, welche über
> ein Python-Programm "repo" verwaltet werden:

Falls das gerade nicht ganz klar rüberkam - das "repo" Tool kann auch 
ohne Android benutzt werden (ist sogar in den Ubuntu-Paketquellen) und 
sollte sich problemlos für eigene Projekte einsetzen lassen. Es ist ein 
recht stabiles Tool und funktioniert i.A. gut. Das ist ziemlich genau 
das was gesucht wird! Submodule sind meiner Erfahrung nach nicht so 
flexibel und skalierbar.

Siehe auch:
https://www.edureka.co/blog/git-submodules-versus-googles-repo-tool
Wobei ich zum Punkt "Hard to reconstruct old versions." sagen muss, dass 
man auch fixe Versions-Kombinationen definieren kann, indem man 
entsprechende Manifeste mit Versions-Commits erzeugt. Muss man dann 
genau so pflegen wie normale git-commits.

von Bernd K. (prof7bit)


Lesenswert?

H. R. schrieb:
> Ich errinere mich an ein Projekt der aus knapp 40 einzelne repos
> bestand. es gab ein tcl script der bei einem release ein git Tag über
> alle repos gezogen hat.
>
> und es gab ein script der alle repos entweder basierend auf ein tag,
> oder überall den top of the tree gecloned hat.

Das halte ich weiterhin für die beste Methode. Vielleicht kann man die 
Hauptarbeit vom oben erwähnten repo tool machen lassen. Da passiert dann 
kein versteckter Hokuspokus im Hintergrund und das Script wird simpel 
und straightforward sein, alles zentral an einer Stelle und einfach zu 
überblicken. Mit git submodule bekommst Du es auch nicht besser hin, es 
wird damit nur fummeliger, unübersichtlicher und leichter sich in den 
Fuß zu schießen und scripten mußt Du da erst recht denn ansonsten 
verlierst Du die Kontrolle und schießt Dir jeden Tag zweimal in den Fuß 
bei 40 Untermodulen.

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.