Vincent Ordy ordy@lrde.epita.fr writes:
Alexandre Duret-Lutz wrote:
"VO" == Vincent Ordy ordy@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
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 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 :)
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).
[...]
"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.
http://www.google.com/search?q=vim+changelog+mode
[...]
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é.
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.