Quelques critiques...
>>> "VO" == Vincent Ordy <ordy(a)lrde.epita.fr> writes:
[...]
VO> +# Check 80 columns.
VO> +if grep -q '^.\{80,\}' "$file"; then
VO> + warning 'Please avoid long lines in your ChangeLog entry (80 columns max):'
VO> + grep >&2 '^.\{80,\}' "$file"
VO> + error=true
VO> +fi
1) Une tabulation devrait compter pour 8 colonnes dans un ChangeLog
=> il faudrait utiliser "expand" avant grep.
2) Vaucanson contient des noms de fichiers de plus de 80 caractères.
Découper un nom de fichier pour le faire tenir sur 80 colonnes
ne me paraît pas souhaitable car ça empêche d'utiliser grep ensuite.
En fait c'est un cas où il me semble raisonnable de ne pas imposer
les 80 colonnes. Peut-être peux-tu ignorer les lignes qui
n'ont pas d'espace (de la forme "^\t[^ ]*$") avant de compter les
colonnes.
VO> +++ b/trunk/git-hooks/post-commit
[...]
VO> +## Add the log to the ChangeLog
VO> +mv "$changelog" "$changelog".old
VO> +git > "$changelog" \
VO> + log -n1 --date=short \
VO> + --pretty="format:%ad %an <%ae>%n%n %s%n%n%b%n"
VO> +cat >> "$changelog" "$changelog".old
VO> +rm "$changelog".old
VO> +
VO> +## Amend the last commit to add the ChangeLog
VO> +git add "$changelog"
VO> +tree_ref=$(git write-tree)
VO> +commit_ref=$(git log -n1 --pretty="format:%s%n%n%b%n" | \
VO> + git commit-tree $tree_ref -p 'HEAD^')
VO> +git update-ref HEAD $commit_ref
VO> +git gc --auto
Perso il est hors de question que j'utilise un truc pareil.
L'intérêt de git est justement que je peux faire plein de
commits intermédiaires : certains qui disparaîtront par la
suite, d'autres qui seront fusionnés et pour lesquels j'écrirai
le ChangeLog plus tard, ou bien des commits que je réordonnerai
avant de les rendre publiques. Je ne veux pas que mon ChangeLog
soit pollué systématiquement avec ma cuisine.
Par hasard est-ce que ce "truc" ne rajouterait pas une
entrée de ChangeLog si j'essaye de modifier une typo
dans le dernier message de commit avec "commit --amend" ?
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.
- 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.
- ne plus écrire de ChangeLog et ne même plus les générer
(c'est l'approche de Linux).
Pour nous développeurs, les ChangeLogs ne nous servent plus à
grand chose à partir du moment où l'on a une copie du dépôt git
en local. Mais comme on ne distribue pas le dépôt git en même
temps que les sources dans une release, c'est un peu dur de
respecter les GPL sans trimbaler de ChangeLog (au moins pour les
parties du projets dont nous ne sommes pas propriétaires) :
« a) You must cause the modified files to carry prominent
notices stating that you changed the files and the date of
any change. »
--
Alexandre Duret-Lutz
