Guten Morgen Forum!
Ich überlege derzeit alle Mikrocontroller-Sourcen mit GIT zu
versionieren.
Dabei möchte ich bestimmte Komponenten bzw. Librarys getrennt als
"Gemeinsame Komponenten" oder "Common Components" getrennt verwalten.
Beispiel: Ich erstelle ein neues Projekt und lege ein Responsitory an.
In das Verzeichnis soll jetzt meine LCD-Library aus einem anderen Repo
geshared werden. Diese Library kann ich nun in das neue Projekt
einbinden.
Wenn ich an den LCD-Routinen was verändere möchte ich das wieder global
adden/commiten, so das die änderungen ggf. in anderen Projekten schnell
einfließen können.
Uff, ist das denglisch ....
Geht das so einfach mit GIT? Gibt es da was zu beachten?
Vg!
K.
Ich rate von der Verwendung von git submodule ab. Bau doch die
gemeinsamen Sachen in eine Static Library (.a), installiere die
gemeinsam genutzen Header und diese Library irgendwo hin, und linke
dagegen.
Hi Katafish,
genau sowas wollte ich auch mal in git umsetzen.
Sogern ich git auch mag, ich muss leider sagen, bei diesem Thema sind
andere Versionsverwaltungen stärker.
git submodule hab ich auch ausprobiert, klappt auch irgendwie, aber ist
bisl fummelig.
Hab aber dann auch ned soo viel Zeit da reingesteckt.
Klaus schrieb:> Sven B. schrieb:>> Ich rate von der Verwendung von git submodule ab.>> Was genau spricht dagegen? Magst Du das mal erläutern?
Es gibt kein so richtiges Totschlagargument, aber wie lex sagte, es ist
einfach irgendwie immer fummelig. Du brauchst mehrere Befehle beim
Klonen um ein funktionierendes Repo zu erhalten, du brauchst mehrere
Befehle um das Repo zu aktualisieren, wenn du irgendwas davon vergisst
passieren u.U. komische Dinge. git-describe gibt dir keine verlässliche
Beschreibung des Zustands der Repository mehr. Immer wenn ich mit git
submodule zu tun hatte traten irgendwelche unerwarteten Probleme auf
(und ich bin da nicht allein, du kannst ja mal ein bisschen rumgoogeln).
Und es bringt dir einfach nicht wirklich einen Vorteil in diesem Fall
gegenüber der Static Library-Lösung.
Ich würde sogar behaupten es bringt dir nichtmal wirklich einen klaren
Vorteil gegenüber dem einfach die ganze Lib in das Repo zu kopieren. So
gut wie du "git submodule update" tippen kannst, kannst du auch die
seitdem passierten Änderungen in der Bibliothek als Patches in deine
Kopie reinziehen. Und dann ist es wenigstens einfach und intuitiv zu
benutzen und du kannst trivial lokale Anpassungen für ein einzelnes
Projekt vornehmen.
Wenn man sich einmal damit befasst hat wie das mit dem submodulen läuft
klappt das eigentlich sehr gut.
Ja, ich brauche nicht ein kommando um ein repository auszuschecken, ich
brauch 2. Das bringt aber niemanden um hoffe ich.
Das was man verstehen musst ist das man aus sicht des hauptrepositories
sumbodule wie eine einzelne datei behandelt wenn man den "inhalt"
ändert.
Wenn du also z.b. deine Lib in einer neuen version releast hast dann
checkst du im submodul ordner den passenden tag, branch, oder commit
aus, wie auch immer du das handlest.
wenn du jetzt git im haupt-repository nach dem status des repositories
fragst wirst du feststellen das sich das submodul verändert hat. das
kannst du jetzt commiten.
Damit comittest du aber nicht die geänderten Dateien sondern nur den
Zeiger des Submoduls auf den aktuellen Stand.
Also mit dem --recursive reicht bei mir auch ein Kommando um alle
submodule auf einmal mit auszuchecken. Auch bei mehrfach verschachtelten
Repositories.
Clemens N. schrieb:> Also mit dem --recursive reicht bei mir auch ein Kommando um alle> submodule auf einmal mit auszuchecken. Auch bei mehrfach verschachtelten> Repositories.
Das ja, aber beim initialen clone musst du dann anschließend noch dein
git submodules... ausführen.
Wenn das aber eon ko-kriterium ist...
Ich grab den Fred mal wieder raus.
Das Thema ist immer noch aktuell.
Aufgrund von wenig Zeit geriet das etwas in den Hintergrund.
Nun hab ich mich mal mehr mit GIT auseinander gesetzt.
Die Grundlegende Funktion und das Handling sind soweit klar.
Thema submodule:
Static Libraries finde ich für mich weniger interessant. Da nehme ich
lieber etwas mehraufwand in Kauf und nutze submodules.
Um das auszuprobieren habe ich ein fiktives Testprojekt erstellt und
drauf los getestet.
Dabei sind nun Fragen aufgekommen, die ich mit Hilfe der Man-Pages nicht
beantworten konnte.
1. Speichert GIT die Pfade zu dem Ursprung des Submodules absolut oder
relativ?
2. Änderungen in Submodules:
Projekt A enthält eine Biliothek, welche ich als Submodule in Projekt B
einfügen möchte.
Wenn sich die Sourcen in Projekt A ändern, kann ich diese mit pull im
Projekt B aktualisieren.
Nun fällt mir aber auf, während ich Projekt B bearbeite, das ein Bug in
dem submodule enthalten ist. Ich behebe den Bug im Projekt B und möchte
die Änderungen zurück zu Projekt A senden.
Ein normaler push geht nicht, da Projekt A und B beide im Master-branch
sind.
Kann ich per push sagen, das die geänderten Sourcen aus dem submodule
von Projekt B in einen neuen Branch in Projekt A eingefügt werden? Denn
dann kann ich anschließend bei Projekt A den Änderungs-Branch mit dem
Master mergen.
Vg!
Katatafish
Und genau diese Szenarien sind (für mich) unheimlich frickelig mit
submodulen zu handhaben. Eine alternative sind wohl subtrees, hier mal
eine Übersicht https://gist.github.com/kvnsmth/4688345.
Foobar schrieb:> Und genau diese Szenarien sind (für mich) unheimlich frickelig mit> submodulen zu handhaben.
Genau so ist es. Deshalb der Rat, keine Submodules zu benutzen. ;p
Katafish schrieb:> Nun fällt mir aber auf, während ich Projekt B bearbeite, das ein Bug in> dem submodule enthalten ist. Ich behebe den Bug im Projekt B ...
Nein! Bugreport für Projekt A erstellen mit einem Patch zur Behebung als
Attachment und dann auf das neue Release von Projekt A warten und hoffen
dass das Projektteam A den Bug behoben hat ;-)
wenn du in 2 projekten ne lib nutzen willst dann brauchst du 3 repos um
das sinnvoll zu machen:
1: repo für projekt a
2: repo für Projekt b
3: repo für lib x
dann kannst du pib x als submodule in projekt a und projekt b
auschecken.
Das ist ein zweischneidiges Schwert.
Ich bin mittlerweile wieder dazu übergegangen jeweils Kopien der
fraglichen mehrfach verwendeten Dateien in ihrem damaligen Zustand
direkt in das Repository des jeweiligen Projekts einzuchecken, die
können im Einzelfall auch mal deutlich auseinander laufen, nicht alles
ist so generisch dass man es ohne Anpassungen überall benutzen kann,
oftmals hat da der Pragmatismus gesiegt. Das Vorgehen halte ich unter
diesen Umständen für einfacher handhabbar als noch in jedem Projekt zwei
bis fünf verschiedene Submodul-Repositories zu haben mit zig
verschiedenen Branches, praktisch für jedes Projekt seinen eigenen
Branch damit nichts versehentlich verrutschen kann.
Stattdessen arbeite ich intensiv mit Meld, pflege für jede solche "lib"
oder mehrfach nutzbare Datei genau eine Master-Version in ihren eigenen
Repository die immer alle für gut befundenen Verbesserungen enthält und
die schmutzigen Hacks für einzelne Projekte bleiben in den einzelnen
Projekten.
Und jedesmal wenn ich ein uraltes (aber noch produktives) Projekt wieder
anfassen muss weil irgend ne Kleinigkeit verändert werden muss
entscheide ich von Fall zu Fall welche Teile der mittlerweile
angefallenen Verbesserungen der gemeinsam verwendeten Libs gebrauchen
kann (oder will) und gefahrlos reinmergen kann ohne mich in eine
tagelange Refactoring und Test-Hölle wegen geändertem API begeben zu
müssen, nur weil ich eigentlich nur schnell zwei Zeilen ändern wollte.
