[AUR] Meilleur méthode pour un super-projet Git ? (Résolu)

[Xorg]

Salut tout le monde.

Depuis que AUR 4 est apparu, je ne sais pas trop comment m'y prendre pour regrouper tous mes paquets dans un même dépôt Git (ce qu'on qualifie de super-projet il me semble).
J'ai bien trouvé 3 méthodes, mais je ne suis pas certains qu'elles conviennent à mes attentes :
- La première est très sale, il suffit d'avoir un dépôt maître et de cloner un par un tous les paquets dedans (avec un git clone ssh+git://aur@aur.archlinux.org/<paquet>.git). Problème : on ne peut pas récupérer tous les paquets d'un coup avec cette méthode.
- La deuxième est certainement la plus populaire : dans le dépôt maître, ajouter des sous-modules avec git submodule add ssh+git://aur@aur.archlinux.org/<paquet>.git. Problème : si je mets à jour un paquet puis que je décide de faire un nouveau clone du dépôt maître avec git clone --recursive, ça va me cloner les sous-modules mais en ignorant les nouveaux commits (donc je verrais l'ancienne version en gros).
- La troisième méthode, que j'avais pensé être la bonne, est de "tracker" la branche master du sous-module : toujours dans le dépôt maître, git submodule add -b master ssh+git://aur@aur.archlinux.org/<paquet>.git. Problème : le même qu'avec la précédente méthode, et j'ai aussi un joli HEAD détachée sur xxxxxxx lorsque je fais un git status dans un sous-module.

Avec les deux dernières méthodes, pour forcer la mise à jour de tous les sous-modules vers la version la plus récente, j'ai trouvé la commande git submodule foreach git pull origin master qui fonctionne bien.
Mais un git status dans le dépôt maître me dit :

Code : Tout sélectionner

modifié :         <paquet> (nouveaux commits)

Voici le fichier .gitmodules (dans le dépôt).

Il y a quelque chose à faire pour éviter de devoir faire des git submodule foreach git pull origin master et ne pas avoir le message "nouveaux commits" dans le dépôt maître ?

Merci d'avance.

[benjarobin]

Bonjour,
Alors ceci est tout à fait normal. Tout d'abord tu dois utiliser la 2ième méthode.
Les messages "nouveaux commits" dans le dépôt maître sont normales, car le dépôt maître gère de manière cohérente un ensemble de sous modules. Il faut donc faire un commit depuis le dépôt maître pour ne plus avoir ce genre de message : git commit -a

Pour voir les changements réalisés dans les sous modules (les commits) depuis le dépôt maître tu peux modifier la configuration suivante

Code : Tout sélectionner

git config --global status.submoduleSummary true

[Xorg]

Donc ça voudrait dire qu'il faut que je vire toutes les lignes branch = master du .gitmodules ? Je les avais mises pour tracker master en fait.

C'est quand même dommage de devoir commiter deux fois le même changement (un dans chaque dépôt), ça m'étonne un peu qu'il n'y ait rien de plus simple.

[benjarobin]

Dans ton cas, je ne comprend absolument pas le besoin d'un super-projet Git, si tu ne veux pas gérer de cohérence entre tes sous modules alors un simple dossier avec un script bash fait l'affaire.
En faite je ne comprend pas du tout ton besoin... Les gits étant totalement indépendant entre eux.

[Xorg]

Le besoin c'est d'avoir un répertoire qui contient des sous-répertoires représentants chaque paquets. Le but c'est de récupérer tous ces sous-répertoires avec un seul git clone, d'où pourquoi j'ai écarté le script Bash. Je voulais vraiment qu'en une commande, tous les paquets soient récupérés. Je sais, c'est une forme de fainéantise, je me casse certainement plus la tête à vouloir y mettre en place, mais quand ça fonctionne on peut être fier de travail fait. J'ai pas l'impression d'être si loin du résultat, et je pense qu'un git commit -a dans le dépôt maître comme tu me l'as dit peut résoudre le problème.

J'ai bien compris que les dépôts sont tous indépendants entre eux, je ne comprenais pas pourquoi le dépôt maître voit les modifications effectuées dans les sous-modules, c'est juste que je n'avais pas bien compris cette histoire de cohérence.

Je pense qu'un hook post-commit dans les sous-modules qui commit automatiquement dans le dépôt maître devrait faire l'affaire, je vais tester 2-3 trucs.

[benjarobin]

Tu peux très bien avoir un git qui contient uniquement un script bash. Se dernier ayant différente fonctions : clone, pull, fetch, push... Après oui tu peux essayer de bricoler quelque chose avec les submodules

[Xorg]

J'ai mis un hook post-commit dans un sous-module, il est bien exécuté lors d'un commit dans le sous-module. Mais visiblement le commit avec le message "HOOK" dedans est refait dans le sous-module et non le dépôt maître.

Code : Tout sélectionner

#!/bin/sh

echo "Début hook"
msg=$(git log -1 --pretty=%B)
rep=$(basename $PWD)
cd ..
git commit "$rep" -m "$msg HOOK"
echo "Fin hook"

J'ai essayé de mettre le chemin du dépôt maître avec --work-tree, c'est pareil. Je ne comprends pas pourquoi ça ne fonctionne pas, il doit y avoir quelque chose qui m'échappe dans les hooks...

[benjarobin]

A placer dans .git/modules/nom-sub-module/hooks/post-commit

Code : Tout sélectionner

#!/bin/sh

echo "Début hook"
msg="$(git log -1 --pretty=%B)"
rep="$(basename $PWD)"
unset GIT_INDEX_FILE  GIT_DIR GIT_WORK_TREE GIT_PREFIX
cd ..
git add "$rep"
git commit -m "$msg HOOK"
echo "Fin hook"

[Xorg]

C'est génial, ça marche du tonnerre, dans mes essais j'avais essayé de changer uniquement la variable GIT_WORK_TREE, c'est pour ça que ça ne n'allait pas. Merci énormément.

Bon, j'avais pourtant réajouté mes modules sans tracker la branche master (.gitmodules), mais je me retrouve encore avec un HEAD détaché dans les sous-modules lorsque je fais un git clone --recursive <dépôt_maître>. C'est normal ou j'ai encore foiré quelque part ?

[benjarobin]

C'est normal, en effet le dépôt maître lors du clone va placer les sous dépôts à une révision précise : donc HEAD détaché

[Xorg]

Ok, alors c'est quoi la différence un sous-module standard et un qui suit la branche master dans ce cas là ?
Comme tu l'auras compris, je ne suis pas trop familier avec les sous-modules, mais il faut bien un début à tout.

[Xorg]

Bon, c'était vraiment se casser la tête pour rien... Après pour appliquer les hooks automatiquement, j'ai vu qu'on peut utiliser des templates, et si le hook de post-commit se retrouve dans .git/hooks du dépôt maître, ça va poser problème, donc il faudrait encore que j'ajoute une condition dans le hook de post-commit. J'ai vu que la configuration des templates était locale à la machine, je préfère oublier les templates, ce n'est pas ce que je cherche à faire de toute façon.

J'ai ajouté un script post-clone.sh qui s'occupe d'activer les hooks pour les sous-modules uniquement, et j'en profite pour rebrancher HEAD sur master dans ce script.

Donc ça revient à ce que tu disais, il faut que j'exécute un script après clone... Comme tu me l'avais conseillé, un script qui clone automatiquement les sous-modules aurait été plus simple, je l'avoue.

Fainéantisme jusqu'au bout, j'ai un alias git qui appelle la fonction _git :

Code : Tout sélectionner

_git() {
	git $@

	[[ $1 == "clone" ]] && $(echo $@ | grep -q "git@github.com:X0rg/AUR-PKGBUILD") && cd "$PWD/AUR-PKGBUILD" && "./scripts/post-clone.sh"
}

Certains diront que la philosophie KISS n'est pas de la partie, et d'autres diront pourquoi faire simple quand on peut faire compliqué.

Je mets le sujet en résolu, la réponse à la question est que les sous-modules sont un vrai bourbier à mettre en place. Mais une fois que ça tourne, ça sert à rien de changer pour autre chose.

[Xorg]

Je remonte ce sujet car, après quelques mois d'utilisations de cette méthode, je n'ai pas été entièrement convaincu (mais cette méthode a des points positifs, tout de même).

Quelques inconvénients de cette méthode :
- Il ne faut pas oublier le --recursive, ou un git submodule update --init --recursive le cas échéant
- Les interfaces web, telle celle de GitHub, ne permettent pas de voir le contenu des sous-modules
- Les sous-modules sont marqués comme "dirty" par le dépôt maître en cas de modifications

J'ai un peu farfouillé sur GitHub pour voir comment font certains utilisateurs, j'ai trouvé quelques personnes qui utilisent des sous-modules elles aussi, mais la plupart des autres continuent d'utiliser des répertoires (à la sauce pré-AUR4). J'ai vu des scripts chez certains, dont notamment à base de subtree, et ça m'a donné des idées.

Du coup, j'ai abandonné les sous-modules, et j'ai modifié la façon de procéder. L'idée est la suivante :
- Modification du paquet dans mon répertoire personnel (c'est donc la version locale du dépôt GitHub)
- Le hook de pre-commit met à jour les sommes de contrôle et le fichier .SRCINFO (il supprime aussi les fichiers qui viennent d'être téléchargé par updpkgsums)
- Le hook de post-commit récupère le paquet sur AUR et il applique automatiquement les modifications (il rajoute aussi le nom du paquet dans le message du commit, uniquement sur le dépôt GitHub)
- Le hook de pre-push permet de faire deux push en un (c'est-à-dire que ça push sur AUR puis sur GitHub)

J'ai mon script post_clone.sh qui permet d'appliquer ces hooks. Bref, de ce que j'ai testé, je suis plutôt satisfait du résultat, même si ça "duplique" les paquets en fin de compte.

[papajoke]

Bonjour,
sans sous-modules ! pour synchroniser un dépot aur et github pas de hook simplement je donne les deux url au dépot :

Code : Tout sélectionner

git remote set-url origin --push --add https://github.com/<login>/<paquet-aur4>.git
git remote set-url origin --push --add ssh+git://aur@aur.archlinux.org/<paquet-aur4>.git

[Xorg]

sans sous-modules !

Tu as un dépôt sur GitHub par paquet, non ? J'utilise un seul dépôt pour tous mes paquets sur GitHub (ici).