17 Feb
2009
17 Feb
'09
7:03 p.m.
Alexandre Duret-Lutz wrote:
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.
[...]
>>
"VO" == Vincent Ordy <ordy(a)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
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 :
1. 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
2. git add ... de tous les fichiers que je veux commiter
3. git diff --cached pour relire ce que j'ai préparé
4. je termine le ChangeLog, toujours dans mon éditeur
5. 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.
--
Vincent Ordy