Alexandre Duret-Lutz wrote:
Quelques critiques...
"VO" == Vincent Ordy ordy@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
Une tabulation devrait compter pour 8 colonnes dans un ChangeLog => il faudrait utiliser "expand" avant grep.
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.
C'est vrai pour les 2, mais ce code vient de svn-wrapper. Donc vous deviez déjà avoir le problème, comment le gériez-vous ?
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.
C'est moche oui. Mais perso je préfère enlever des trucs du ChangeLog que de devoir en rajouter
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.
1/ On n'utilise pas tous le même éditeur. Chez les 2009, sur 9 étudiants, il y en avait 4 qui utilisaient vim. Tu veux vraiment faire un script/macro pour chaque éditeur ? :D
2/ On ne va pas pouvoir générer facilement la liste des fichiers à inclure dans le commit dans le ChangeLog. À cause de la syntaxe très pratique "git commit mon_fichier". Quand on fait ça, git internement sauvegarde l'index, fait le commit, et si ça faile il rollback l'index. Je ne connais pas de moyen facile de jouer comme ça en ligne de commande avec l'index.
Ça nous permet d'appeler "git commit" normalement pour les commits moins formels.
C'est vrai qu'à cause du fait que ça soit dans le post-commit on ne peut même pas utiliser --no-verify...
- 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.
Ça peut se faire, mais certains projets ne sont releasés que (trop) rarement.
Autre problème: si un commit est modifié APRÈS une release, il n'est pas modifié dans la ChangeLog. Ok, ça ne devrait jamais arriver, mais bon...
- ne plus écrire de ChangeLog et ne même plus les générer (c'est l'approche de Linux).
Je suis pour, mais ce n'est pas de mon ressort, c'est demandé de l'écrire dans le guide, et pour le moment j'en ai juste marre de faire à la main: - mon commit - ouvrir mon éditeur et lancer la macro qui prend le premier commit de git log - amender le dernier commit pour rajouter le ChangeLog
Donc en attendant mieux... j'utilise cette horreur écrite en une demi-heure.