Gitversion prend ses aises, partie 2

Juste un rebond sur mon fil précédent : je suis allé voir ce qu'il en était de git lui même. Et bien, je n'ai pas été déçu : avec grosso modo une dépendance sur la libc, sur zlib, et sur les regex perl, git tient dans à peine plus que 3 megs. Il fait donc à peu près 100 fois plus que gitversion, en 20 fois moins de place. Yay !

Git et les sous-modules

Je viens de découvrir le concept des sous-modules dans Git, et je trouve ça vachement malin.

En effet, il fut un temps où pour construire une bibliothèque ou application tierce, il fallait commencer par aller chercher tout un tas de dépendances, les construire, les installer, et ainsi de suite, en espérant ne pas trop se tromper dans les versions. Un cauchemard.

Et pourtant, j'ai découvert que maintenant, nombre de projets sur Github incluent directement leurs dépendances sous forme de sous-modules, ce qui fait que l'on clone le dépôt, qui ensuite va cloner d'autres dépôts dans les répertoires qui vont bien, et ainsi de suite. Et surtout, le dépôt principal enregistre non seulement le lien vers le sous-dépôt, mais la version du code, ce qui permet de récupérer exactement la bonne version.

Voyez par exemple ce dépôt : dans son sous-répertoire "externals", il possède un lien vers les dépôts de gli et de glm, à une version donnée. Glm, par exemple, peut avancer, et produire un changement qui casse la compatibilité. Si je clone Vulkan-glTF-PBR en utilisant la commande "git clone --recursive", je vais récupérer la version ancienne de Glm. Je peux ensuite si je le souhaite bouger la version GLM pointée, corriger le code pour que ça compile, et envoyer la pull request.

J'ai commencé à utiliser cette approche pour séparer mon moteur de rendu de la démo qui l'utilise: ainsi, je peux avancer sur le moteur à travers une démo, puis créer une nouvelle démo qui pointe vers ce même moteur et avancer sur un autre point. Ainsi, le code du moteur reste propre, et il est particulièrement simple de cloner une démo et de commencer à coder. Pas besoin de gérer chemins ou variables d'environnement, tout est à la bonne place.

Partageons

C'est toujours mieux quand on partage, donc j'ai mis une version très basique de mon explorateur de l'ensemble de Mandelbrot, version ordinateur de bureau, sur Github. C'est par ici que ça se passe.

Notez que j'ai trouvé une fonction pour transformer du HSV en RGB, histoire de fournir une coloration continue. Wikipedia l'explique mieux que moi, mais l'idée est que la composante H (la teinte) correspond à une position sur un cercle, l'ensemble HSV étant un cylindre, par opposition au RGB qui est un cube, et que la faire varier permet donc de changer de teinte aussi rapidement que souhaité sans jamais avoir de "saut" peu esthétique dans les couleurs.

Une gallerie en wxWidgets

C'est basique, mais ça fait le boulot. Je viens de merger la branche gallerie dans la branche principale, maintenant que mon contrôle de galerie d'images est suffisamment fonctionnel. Voici la bête:



Vu que je n'avais rien modifié dans ma branche principale, le merge a été particulièrement simple:

git branch master <= hop, de retour sur la branche princpale
git merge gallery <= on merge la gallerie, de fait un simple fast forward
git branch -d gallery <= et on détruit la branche devenue inutile

Il reste encore à permettre le réarrangement des pages, et on devrait être fonctionnellement complet.

Github - Ça vient doucement...

Aujourd'hui, je me suis mis à implémenter une vraie galerie d'images au lieu de la bête listbox, pour représenter la liste des images déjà importées. Ce fut donc l'occasion d'essayer de comprendre comment faire une branche sur git, et la pousser sur github. Avec l'aide de StackOverflow, voilà ce que je fis:

Tout d'abord, créer une nouvelle branche à l'aide de la commande "checkout":

# git checkout -b gallery

Git me confirme que mes changements sont maintenant bien situés sur la branche, et m'indique "Switched to a new branch 'gallery'".

# git branch

* gallery
master

C'est bien la confirmation que j'ai maintenant deux branches, et que ma branche courante est gallery. Ouf!

# git commit

# git push origin gallery

Voilà, ma branche est partie sur github. Je vérifie sur le graphe des branches que tout est bien comme je m'y attendais.

Je vais finir par y comprendre quelque chose.

OCaml détecté

Yay, Github a manifestement refait tourner les statistiques, et détecte bien maintenant que Médoc est fait à 45% d'OCaml.

Je commence à apprécier Github

Ce site est un vrai petit bijou. Je découvre leur système de tickets, qui permet de lever des bugs ou des feature requests, de les assigner à un développeur et à une release et de les tagger. Ensuite, lorsque l'on corrige le ticket n, il suffit d'avoir "fix #n", "fixes #n", "close #n" ou "closes #n" dans le message de commit. Par exemple, mon dernier commit: "Added possibility to clear all loaded images. Fixes #1." ferme automatiquement le ticket correspondant, en y incluant le commentaire et un lien vers le commit, et ceci, pratiquement immédiatement après le push.

Par contre, étrangement, les statistiques en termes de langages utilisés ont l'air un poil cassé: j'ai commité ce week-end un millier de lignes d'OCaml et un peu de SQL, mais Github indique obstinément 100% de C++.