Für Mikrocontrollerprojekte: GIT mit Geimeinsamen Komponenten

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.

abo

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

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.