6 May
2009
6 May
'09
4:16 p.m.
Alexandre Duret-Lutz <adl(a)lrde.epita.fr> writes:
Quelques critiques...
:)
[...]
Non, non, franchement pour éviter le travail de
dupliquer
les messages des commits et du ChangeLog je vois d'autres
solutions :
- écrire le ChangeLog confortablement (p.ex. à l'aide
de "C-x 4 a" sous emacs) et avoir un script qui appelle
"git commit" en lui passant le texte de la dernière entrée.
Ça nous permet d'appeler "git commit" normalement pour
les commits moins formels.
C'est ma solution préférée, après celle qui vient.
- ne plus écrire de ChangeLog, mais les générer
automatiquement juste avant de faire une release (c'est
l'approche de GNU Coreutils et de Xorg); ça simplifie
les merges.
C'est le meilleur compromis je trouve : un script qui génère un
ChangeLog à partir des messages du dépôt, et qui note quelque part quels
commits ont été pris en compte.
1. ça permet d'avoir un vrai fichier ChangeLog dans le dépôt, qu'on peut
lire avec un vrai éditeur (pas forcément toujours à jour, mais c'est
pas très grave) ;
2. ça évite le problème de duplication (et de divergence !) entre
messages Git et entrées de ChangeLog ;
3. ça permet de *corriger* les ChangeLog ; dans les solutions où tout
est généré, on a l'air malin lorsque des entrées sont vides,
comportent des fautes ou sont incomplète. Au moins, on se donne une
chance de pouvoir corriger. Rappel : on ne veut bien sûr pas
modifier le dépôt (publié), puisque c'est une pratique à proscrire.
Comme on garde sous le coude (dans le dépôt) le dernier commit pris en
compte par le ChangeLog, la prochaine fois qu'on le régénèrera, on ne
lui ajoutera que les entrées nouvelles.
C'est vraiment la solution que je préfère, et que j'ai envie d'utiliser
dans Olena et Tiger.
- ne plus écrire de ChangeLog et ne même plus les
générer (c'est
l'approche de Linux).
Arg !