J'ai essayé les sous-modules ainsi qu'une ou deux autres solutions mais je les ai rapidement rejetées par rapport à mon contexte. En effet :
mes collègues utilisent exclusivement une interface graphique pour interagir avec git (TortoiseGit majoritairement). A l'époque où j'ai écrit Multigit, aucun client git graphique ne fournissait une gestion des sous-modules. Pour eux, ça n'auraient pas été utilisable.
les sous-modules demandent un apprentissage nouveau au dessus de git. Les commandes n'ont pas les mêmes noms, et il y a des opérations en plus à effectuer. Une grande partie de mes collègues (surtout il y a 4 ans) étaient déjà à la peine avec l'utilisation de git toute simple. Mon objectif est de leur simplifier la vie, pas de la leur rendre plus complexe.
comme le décrit si bien AncalagonTotof, avec les sous-modules, on peut se rater. Ça offre encore plus de façon de se planter avant d'arriver à un résultat attendu. Notamment, il faut être très attentif au répertoire dans lequel on lance sa commande car le résultat peut n'avoir rien à voir.
Mon objectif en écrivant Multigit était vraiment la simplicité pour tout le monde:
pouvoir d'un coup d'oeil identifier les 7 dépôts modifiés parmi les 67 dépôts du projet et prendre quelques secondes pour vérifier le diff sur chacun
pouvoir faire les opérations du quotidien sur tous les dépôts ou un sous-ensemble de dépôt de façon très simple
utiliser uniquement des commandes git standard, visibles dans le log, de façon à ce que tout le monde comprenne ce qui se passe
D'après mes collègues, j'ai plutôt réussi ma mission. Et je suis tout fier quand je vois qu'il est sur tous les écrans des développeurs de mon boulot.
Cela dit, si les sous-modules marchent bien pour vous, continuez avec. J'ai aussi deux collègues (sur 300) qui en sont très contents et m'ont demandé d'en rajouter le support dans Multigit. J'attends d'avoir plus de demande avant de me lancer
Un truc que les sous-modules font de façon élégante, c'est l'atomicité: un changement sur plusieurs dépôts n'est réellement publié qu'après la mise à jour de dépôt parent. C'est cool, sauf que dans nos projets, on a jamais eu de problème d'atomicité. Par contre, on a très souvent eu des modifs oubliées parce qu'elles étaient dans un dépôt profond que le développeur avait oublié qu'il avait modifié. Et pas mal d'autres problématiques liées uniquement au fait que quand on manipule beaucoup de dépôts, on a vite fait d'en rater un.
[^] # Re: submodules
Posté par Philippe F (site web personnel) . En réponse à la dépêche Première publication libre de Multigit. Évalué à 7.
J'ai essayé les sous-modules ainsi qu'une ou deux autres solutions mais je les ai rapidement rejetées par rapport à mon contexte. En effet :
mes collègues utilisent exclusivement une interface graphique pour interagir avec git (TortoiseGit majoritairement). A l'époque où j'ai écrit Multigit, aucun client git graphique ne fournissait une gestion des sous-modules. Pour eux, ça n'auraient pas été utilisable.
les sous-modules demandent un apprentissage nouveau au dessus de git. Les commandes n'ont pas les mêmes noms, et il y a des opérations en plus à effectuer. Une grande partie de mes collègues (surtout il y a 4 ans) étaient déjà à la peine avec l'utilisation de git toute simple. Mon objectif est de leur simplifier la vie, pas de la leur rendre plus complexe.
comme le décrit si bien AncalagonTotof, avec les sous-modules, on peut se rater. Ça offre encore plus de façon de se planter avant d'arriver à un résultat attendu. Notamment, il faut être très attentif au répertoire dans lequel on lance sa commande car le résultat peut n'avoir rien à voir.
Mon objectif en écrivant Multigit était vraiment la simplicité pour tout le monde:
pouvoir d'un coup d'oeil identifier les 7 dépôts modifiés parmi les 67 dépôts du projet et prendre quelques secondes pour vérifier le diff sur chacun
pouvoir faire les opérations du quotidien sur tous les dépôts ou un sous-ensemble de dépôt de façon très simple
utiliser uniquement des commandes git standard, visibles dans le log, de façon à ce que tout le monde comprenne ce qui se passe
D'après mes collègues, j'ai plutôt réussi ma mission. Et je suis tout fier quand je vois qu'il est sur tous les écrans des développeurs de mon boulot.
Cela dit, si les sous-modules marchent bien pour vous, continuez avec. J'ai aussi deux collègues (sur 300) qui en sont très contents et m'ont demandé d'en rajouter le support dans Multigit. J'attends d'avoir plus de demande avant de me lancer
Un truc que les sous-modules font de façon élégante, c'est l'atomicité: un changement sur plusieurs dépôts n'est réellement publié qu'après la mise à jour de dépôt parent. C'est cool, sauf que dans nos projets, on a jamais eu de problème d'atomicité. Par contre, on a très souvent eu des modifs oubliées parce qu'elles étaient dans un dépôt profond que le développeur avait oublié qu'il avait modifié. Et pas mal d'autres problématiques liées uniquement au fait que quand on manipule beaucoup de dépôts, on a vite fait d'en rater un.