Git Submodules - update din main repo

Am urmatorul setup:

  • main repo;
  • second repo;
  • third repo;

Codul din second si third repo trebuie sa existe separat dar si in main repo. Deci automat m-am gandit la adaugarea acestora ca submodules. Dat fiind ca n-am mai lucrat pana acum cu submodules si din ce am citit pare sa fie mai complicat decat pare la prima vedere, am urmatoarea intrebare: pot sa intervin in main repo cu modificari asupra submodulelor, iar modificarile sa se reflecte fara probleme si in second / third repo?

Daca nu, cum ar trebui procedat? La ce ar trebui sa fiu atent?

Repo-ul părinte ține hash-ul submodulelor.

Cât timp nu ești în situatia de a da push la main repo fără să dai push la un submodul nu ar trebui să ai probleme.

Singurele Majoritatea problemelor avute (de mine) cu submodulele au fost generate fix din cauza asta: uitam să dau push la submodule iar repo-ul principal ajungea pe server cu referințe la hash-uri inexistente.

Mi-am adus aminte și că submodulele sunt ceva mai greu de administrat:

  • nu le poți șterge chiar foarte ușor;
  • dacă ceva merge prost… atunci va merge foarte prost. Te vei lovi de tot felul de erori, care mai de care mai ciudate…

Chiar zilele trecute am avut o problemă dubioasă la un proiect mai vechi (ultimul la care am folosit submodule): nu puteam face git pull. Dădea eroare din cauza submodulelor și nu am găsit nimic relevant online. După vreo 20 minute de încercări, am șters repo-ul local, l-am clonat iar și a mers fără probleme…

Dacă sunt dependințe, eu ți-aș recomanda să folosești un package manager pentru limbajul folosit (composer, npm etc). Mai toate acceptă repo-uri private. (atât la npm cât și la composer poți specifica repo-ul git, nici nu trebuie să înregistrezi pachetul undeva)

Dacă poți să le eviți, evită-le.


Lectură suplimentară:

2 Likes

Dupa mai multa lectura pot sa recomand si eu urmatoarele doua article:

Din care extrag varianta TL/DR:

  1. diff.submodule = log (so you get clearer container diffs when referenced submodule commits changed).
  1. fetch.recurseSubmodules = on-demand (so you are confident new referenced commits for known submodules get fetched with container updates).
  2. status.submoduleSummary = true (so git status gets useful again when a referenced submodule commit changed).

Si articolul referitor la alternativa submodules, si anume subtrees:

In urma ultimului articol am zis sa incerc git-subrepo: https://github.com/ingydotnet/git-subrepo#readme

This git command “clones” an external git repo into a subdirectory of
your repo. Later on, upstream changes can be pulled in, and local
changes can be pushed back. Simple.


@iamntz, sub-modulele nu sunt neaparat dependinte, ar fi diferite plugin-uri care trebuie testate si modificate in main app, dar care pot fi folosite si independent. Prin urmare e nevoie ca un singur push in main app sa actualizeze si repository-urile fiecarui plugin.

In continuare am sentimentul ca trebuie sa fie un setup mai bun pentru problemele de tipul asta.

Îți recomand să fii foarte, foarte reticient în a folosi add-on-uri pentru management-ul dependințelor. În timp, o să-ți dea bătăi de cap și mai mari :slight_smile:

2 Likes

Vad ca mai toata lumea de pe forum, foloseste “dependinte” in loc de “dependente”. Ia uitati ce zice DEX-ul.

DEPENDÍNȚĂ, dependințe, s. f. Încăpere accesorie a unei case de locuit (bucătărie, baie etc.); (la pl.) ansamblul acestor încăperi. – Din fr. dépendances.

3 Likes

Nici eu nu recomand submodules. Le-am văzut dând fail pe destule proiecte ca să fug ca … de tămâie. Prefer compunerea dependințelor folosind un dependency manager adecvar.

Ai o aplicație PHP? Dacă da, acel dependency manager pe care îl cauți se numește composer. Dacă nu, conceptele din spatele metodei se potrivesc oricare ar fi toolsetul tău.

  • faci un repo-second și un repo-third
  • folosești fișierul composer.json pentru a le declara ca dependințe și a încărca acele variante tag-uite pe care ți le dorești
  • ai grijă ca atunci când ai o versiune stabilă de cod în repo-third de exemplu, să o etichetezi ca atare, ca să o poți folosi în main repo

Intre timp am gasit o explicatie mai larga a motivelor pentru care companiile mari migreaza spre repositories monolitice. Stiam de practica aceasta, dar nu mi-am batut capul sa inteleg de ce. Benjamin explica foarte bine.

Azi m-am confruntat cu o situatie in care aveam nevoie sa pun un repository intr-un subdirectory dintr-un alt repository, iar ca sa nu ma complic cu Git Submodules, am pus repository-urile in locatii separate si doar am folosit un symlink.

Grijă mare cu symlinks, cel puțin pe Windows Git poate fi configurat să le ignore (dacă nu mă înșel, e chiar opțiunea default).