Quelques critiques... [...] 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