6 May
2009
6 May
'09
4:01 p.m.
Vincent Ordy <ordy(a)lrde.epita.fr> writes:
De tout mon temps au labo, je n'ai vu grand monde le faire. J'ai juste
suivi ce que les autres faisaient et qu'on m'a montré... je ne me
souvenais même pas qu'il fallait le faire ! Shame on me.
C'est dommage, parce que le guide donne des exemples, et pointe aussi
vers les GNU Coding Standards, qui montrent à quoi ressemble un
ChangeLog, comment ça s'écrit, et pourquoi. Ce serait bien que tout le
monde lise ça.
https://www.lrde.epita.fr/dload/guide/guide.html#htoc92
http://www.gnu.org/prep/standards/html_node/Change-Logs.html
Il est clair que les outils comme Vcs et svn-wrapper permettent de
gagner du temps, mais je déplore également leur mauvaise utilisation.
Ce genre de problème arrive moins lorsque l'on fait des commits de
petite taille : ça permet de mieux voir ce qui a bougé, et Git aide
beaucoup pour ça, vu qu'on a droit à l'erreur en local (git add --amend
et git rebase --interactive).
http://www.google.com/search?q=vim+changelog+mode
Ce n'est pas mon avis. Je pense que git-svn couvre 90% des besoins d'un
participant à un projet du LRDE. Effectivement, tu peux pas modifier
des commits déjà poussés, mais est-ce que tu le ferais vraiment avec un
serveur Git en face ? Modifier un historique déjà publié fait justement
partie des mauvaises pratiques.
IMHO le vrai manque de la solution « git-svn + serveur Subversion »,
c'est qu'on ne peut pas facilement diffuser / partager des branches de
travail personnelles. Mais y'a des work-arounds, comme pousser lesdites
branches de travail vers un dépôt visible sur le Web, de sorte que votre
permanent puisse voir votre travail.
Alexandre Duret-Lutz wrote:
>> "VO" == Vincent Ordy
<ordy(a)lrde.epita.fr> writes:
VO> C'est vrai pour les 2, mais ce code vient de svn-wrapper. Donc vous
VO> deviez déjà avoir le problème, comment le gériez-vous ?
Je n'utilise pas svn-wrapper. D'une part il ne respecte pas ma
façon de travailler en voulant écrire les ChangeLog à ma place,
d'autre part je considère que c'est une des causes de la baisse
de qualité des entrées des ChangeLog des projets du labo :
(1) les gens se contentent d'une simple phrase devant une liste
de fichiers générée automatiquement par svn-wrapper au lieu
de commenter chaque changement
(2) les noms des fonctions modifiées ne sont même pas citées,
par flemme de devoir repasser sur la liste
[...]
Ce que je
suggère est indépendant de l'éditeur. Je veux remplir
le ChangeLog à la main et le message de commit automatiquement,
au lieu de faire l'inverse.
Le script que j'imagine pour aider au commit serait une version
évoluée de :
git-ci() {
git add ChangeLog
git commit -m "`sed '1d;/^....-..-../Q;s/^\t//;' ChangeLog`"
"$@"
}
Avec la façon de travailler suivante :
1. je change ce que je veux, éventuellement je mets à
jour le ChangeLog au fur et à mesure grâce aux fonctions
dédiées de mon éditeur
2. git add ... de tous les fichiers que je veux commiter
3. git diff --cached pour relire ce que j'ai préparé
4. je termine le ChangeLog, toujours dans mon éditeur
5. git-ci pour faire le commit en utilisant ma dernière
entrée de ChangeLog comme message de commit
OK, j'ai toujours connu svn-wrapper, je n'avais pas pensé à faire ça
de cette façon. Je comprends ta façon de faire.
C'est effectivement beaucoup mieux, surtout qu'il m'arrive souvent
d'interrompre ce que j'ai en cours, faire autre chose, puis revenir
sur le premier. Et dans ce cas là, c'est dur de se souvenir de tout ce
qu'on a fait au moment du commit... ta méthode permet même de se
"remettre" plus facilement dans le code qu'on avait stashé (en ayant
le "contexte" grâce au ChangeLog).
Par contre, si on fait comme ça, je m'écrirai au moins pour moi un
hook pour vérifier que la liste des entrées dans le ChangeLog
correspond à celles des fichiers modifiés. Sur certains projets, les
deux seules façons de déboguer étant le "beer debugging" et le
"ça-marche-pas, je-re-checkoute-et-je-réécris-complètement", il y
aurait forcément des inadvertances avec un ChangeLog écrit au fur et à
mesure :) [...]
"C-x 4
a" (je cite emacs parce que c'est ce que je connais, je
ne doute pas vi sache en faire autant) compléter les noms des
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Heeeuuuu, mouais... comment dire... encore une occasion de "tester"
emacs. [...]
Le coup du
post-commit qui modifie le ChangeLog est d'un autre
niveau : là ça t'empêche d'utiliser git pleinement. J'aimerais
beaucoup que personne ne te suive sur cette voie !
De toute façon, utiliser git-svn en soi limite beaucoup l'utilisation
de git. Il est clairement indiqué dans son manuel qu'il est
déconseillé de faire des opérations entre branches
(clone/pull/merge/push), il n'est pas possible de amend/rebase -i un
commit déjà pushé, etc ... En fait, on perd presque tous les intérêts
de git, en dehors de sa rapidité.