[Mode DEV] le sous-module GeoNature et ses sous-modules est cloné plusieurs fois

[lpofredc]

Lors de la mise en place du mode "dev", la commande récursive make submodule_init provoque le clonage récursif de plusieurs GeoNature (avec ses sous-modules également: TaxHub, RefGeo, etc.) du fait que les sous-modules de GeoNature (gn_module_export & gn_module_monitoring) ont également une sous-dépendance à GeoNature.

A priori, les sous-modules GeoNature des modules Dashboard et Export sont inutiles.

$ find . -name GeoNature -type d | xargs du -hd 0
1,1G    ./.git/modules/gn_module_export/modules/dependencies/GeoNature
1,1G    ./.git/modules/gn_module_monitoring/modules/dependencies/GeoNature
1,1G    ./.git/modules/GeoNature # Seul à conserver
49M     ./sources/gn_module_export/dependencies/GeoNature
73M     ./sources/gn_module_monitoring/dependencies/GeoNature
73M     ./sources/GeoNature # Seul à conserver

$ du -hd 1
3,2G    ./.git
28K     ./build
211M    ./sources
56K     ./docs
32K     ./data
24K     ./config
16K     ./assets
12K     ./.github
3,4G    .

[christophe-ramet]

C'est en effet pas idéal… Il faudrait voir si cette dépendance qui existe dans export et import est vraiment essentielle, parce que conceptuellement ça me semble un peu étrange.

Sinon, on pourrait proposer de modifier le submodule_init pour target précisément les différents sous modules :

submodule_init:
	# We can't recurse into every submodule cause some of them also contains GeoNature and we don't want it multiple
	# times
	cd sources && git submodule update --init --recursive GeoNature gn_module_dashboard gn_module_monitoring UsersHub
	cd sources && git submodule update --init gn_module_export gn_module_monitoring
	cd sources/gn_module_export && git submodule update --init dependencies/Utils*

Mais en cas de modification des dépendances, il faudra modifier la règle.

[christophe-ramet]

Le problème étant particulièrement la taille occupée par le clone, pourrait-on envisager d'utiliser l'option suivante :
git submodule update --init --recursive --depth 1
Elle permet de ne cloner que le dernier commit (je n'ai pas testé la solution pour le moment).

[camillemonchicourt]

Oui c'est une bonne solution pour récupérer un dépôt en GIT mais sans s'embarquer tout un historique dont on n'a pas toujours besoin.

[andriacap]

Salut ,

J'ai pu tester la solution , ça accélère l'initialisation des sous modules effectivement mais le problème vient plus tard. Si on veut contribuer , tirer les derniers commits dans un de ces sous modules alors on est confronté à un problème en ayant récupéré que le dernier commit .
J'ai eu des erreurs pour récupérer les derniers developpements des sous modules en faisant un "git submodule update" . Il y a également des problèmes si on veut proproser des développements , pour faire un rebase sur la branche develop du sous module etc .

Bref j'ai l'impression que ce " git submodule update --init --recursive --depth 1" est plus source d'ennui qu'autre chose

[andriacap]

Du coup pour palier le problème que mentionnes @lpofredc , en mode développement nous on fait ça :

Initialisation des sous-modules de premier niveau sans récursivité :

git submodule update --init sources/GeoNature \
                          sources/UsersHub \
                          sources/gn_module_export \
                          sources/gn_module_dashboard \
                          sources/gn_module_monitoring

Et pour GeoNature :

git submodule update --init --recursive sources/GeoNature

A voir pour en faire une règle dans le Makefile.

Ca se rapproche de ce que tu mentionnes ici @christophe-ramet mais ça évite de faire les commandes "cd" etc :

> submodule_init:
> 	# We can't recurse into every submodule cause some of them also contains GeoNature and we don't want it multiple
> 	# times
> 	cd sources && git submodule update --init --recursive GeoNature gn_module_dashboard gn_module_monitoring UsersHub
> 	cd sources && git submodule update --init gn_module_export gn_module_monitoring
> 	cd sources/gn_module_export && git submodule update --init dependencies/Utils*
> ```

[christophe-ramet]

Salut ,

J'ai pu tester la solution , ça accélère l'initialisation des sous modules effectivement mais le problème vient plus tard. Si on veut contribuer , tirer les derniers commits dans un de ces sous modules alors on est confronté à un problème en ayant récupéré que le dernier commit . J'ai eu des erreurs pour récupérer les derniers developpements des sous modules en faisant un "git submodule update" . Il y a également des problèmes si on veut proproser des développements , pour faire un rebase sur la branche develop du sous module etc .

Bref j'ai l'impression que ce " git submodule update --init --recursive --depth 1" est plus source d'ennui qu'autre chose

Je confirme que c'est moins pratique qu'un clone non shallow. La solution avec le update --init ciblé me semble plus pratique même si elle demande un tout petit peu plus de maintenance (si on ajoute des nouveaux sous modules).