Alexandre Duret-Lutz wrote:
"VO" == Vincent Ordy ordy@lrde.epita.fr writes:
VO> C'est vrai pour les 2, mais ce code vient de svn-wrapper. Donc vous VO> deviez déjà avoir le problème, comment le gériez-vous ?
Je n'utilise pas svn-wrapper. D'une part il ne respecte pas ma façon de travailler en voulant écrire les ChangeLog à ma place, d'autre part je considère que c'est une des causes de la baisse de qualité des entrées des ChangeLog des projets du labo : (1) les gens se contentent d'une simple phrase devant une liste de fichiers générée automatiquement par svn-wrapper au lieu de commenter chaque changement (2) les noms des fonctions modifiées ne sont même pas citées, par flemme de devoir repasser sur la liste
De tout mon temps au labo, je n'ai vu grand monde le faire. J'ai juste suivi ce que les autres faisaient et qu'on m'a montré... je ne me souvenais même pas qu'il fallait le faire ! Shame on me.
[...]
Ce que je suggère est indépendant de l'éditeur. Je veux remplir le ChangeLog à la main et le message de commit automatiquement, au lieu de faire l'inverse.
Le script que j'imagine pour aider au commit serait une version évoluée de :
git-ci() { git add ChangeLog git commit -m "`sed '1d;/^....-..-../Q;s/^\t//;' ChangeLog`" "$@" }
Avec la façon de travailler suivante :
- je change ce que je veux, éventuellement je mets à jour le ChangeLog au fur et à mesure grâce aux fonctions dédiées de mon éditeur
- git add ... de tous les fichiers que je veux commiter
- git diff --cached pour relire ce que j'ai préparé
- je termine le ChangeLog, toujours dans mon éditeur
- git-ci pour faire le commit en utilisant ma dernière entrée de ChangeLog comme message de commit
OK, j'ai toujours connu svn-wrapper, je n'avais pas pensé à faire ça de cette façon. Je comprends ta façon de faire. C'est effectivement beaucoup mieux, surtout qu'il m'arrive souvent d'interrompre ce que j'ai en cours, faire autre chose, puis revenir sur le premier. Et dans ce cas là, c'est dur de se souvenir de tout ce qu'on a fait au moment du commit... ta méthode permet même de se "remettre" plus facilement dans le code qu'on avait stashé (en ayant le "contexte" grâce au ChangeLog).
Par contre, si on fait comme ça, je m'écrirai au moins pour moi un hook pour vérifier que la liste des entrées dans le ChangeLog correspond à celles des fichiers modifiés. Sur certains projets, les deux seules façons de déboguer étant le "beer debugging" et le "ça-marche-pas, je-re-checkoute-et-je-réécris-complètement", il y aurait forcément des inadvertances avec un ChangeLog écrit au fur et à mesure :)
[...]
"C-x 4 a" (je cite emacs parce que c'est ce que je connais, je ne doute pas vi sache en faire autant) compléter les noms des
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Heeeuuuu, mouais... comment dire... encore une occasion de "tester" emacs.
[...]
Le coup du post-commit qui modifie le ChangeLog est d'un autre niveau : là ça t'empêche d'utiliser git pleinement. J'aimerais beaucoup que personne ne te suive sur cette voie !
De toute façon, utiliser git-svn en soi limite beaucoup l'utilisation de git. Il est clairement indiqué dans son manuel qu'il est déconseillé de faire des opérations entre branches (clone/pull/merge/push), il n'est pas possible de amend/rebase -i un commit déjà pushé, etc ... En fait, on perd presque tous les intérêts de git, en dehors de sa rapidité.
J'avais vu un post d'Akim pour demander à avoir un serveur git au labo: ça en est où ? Il n'y a pas de réponse sur le thread. S'il y a besoin d'un coup de main je veux bien aider aussi....
Je vais reverter le patch des hooks.