17 Feb
2009
17 Feb
'09
1:26 p.m.
Alexandre Duret-Lutz wrote:
Quelques critiques...
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" == 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.
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.
--
Vincent Ordy