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
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 wrote:
- ne plus écrire de ChangeLog et ne même plus les générer (c'est l'approche de Linux).
Personnellement les ChangeLog, et plus particulièrement les postes des diff sur les news + explications, ça m'a souvent servi. Donc je trouverais ça dommage d'abandonner cette partie là des projets.
"y" == yabo yabo@lrde.epita.fr writes:
y> Alexandre Duret-Lutz wrote:
- ne plus écrire de ChangeLog et ne même plus les générer
(c'est l'approche de Linux).
y> Personnellement les ChangeLog, et plus particulièrement les postes des y> diff sur les news + explications, ça m'a souvent servi. Donc je y> trouverais ça dommage d'abandonner cette partie là des projets.
Je parle juste du fichier ChangeLog, pas des mails (qui contiennent de toute façon le message de commit).
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.
"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
VO> C'est moche oui. Mais perso je préfère enlever des trucs du ChangeLog VO> que de devoir en rajouter
Comme chaque commit ajoute des trucs au ChangeLog, comment fais-tu pour en enlever sans 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.
VO> 1/ On n'utilise pas tous le même éditeur. Chez les 2009, sur 9 VO> étudiants, il y en avait 4 qui utilisaient vim. Tu veux vraiment faire VO> un script/macro pour chaque éditeur ? :D
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
VO> 2/ On ne va pas pouvoir générer facilement la liste des fichiers à VO> inclure dans le commit dans le ChangeLog.
Cf. point (2) plus haut. Un ChangeLog n'est pas qu'une liste de fichiers, on veut aussi voir les fonctions modifiées. Or avec "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 fonctions demande autant de travail que remplir l'entrée complète au fur et à mesure. En ce qui me concerne, je ne vois donc aucun intérêt à générer ces entrées.
Cela dit, écrire le ChangeLog ou le générer : ce n'est pas très grave. Les gens peuvent bien travailler comme ils se sentent le plus efficaces. Ça me fait juste de la peine quand certaines façon de travailler (lire svn-wrapper) semblent encourager un laisser-aller, et du coup j'aimerais bien les décourager.
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 !
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.
[...]
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 :
- 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
- git add ... de tous les fichiers que je veux commiter
- git diff --cached pour relire ce que j'ai préparé
- je termine le ChangeLog, toujours dans mon éditeur
- 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é.
J'avais vu un post d'Akim pour demander à avoir un serveur git au labo: ça en est où ? Il n'y a pas de réponse sur le thread. S'il y a besoin d'un coup de main je veux bien aider aussi....
Je vais reverter le patch des hooks.
"VO" == Vincent Ordy ordy@lrde.epita.fr writes:
VO> Par contre, si on fait comme ça, je m'écrirai au moins pour moi un VO> hook pour vérifier que la liste des entrées dans le ChangeLog VO> correspond à celles des fichiers modifiés.
Ça permettrait entre autre de détecter des oublis de "git add".
VO> J'avais vu un post d'Akim pour demander à avoir un serveur git au VO> labo: ça en est où ?
Djo est en train d'installer ça ; c'est pour bientôt.
J'ai installe un serveur (git.lrde.org) accessible depuis l'interieur et l'exterieur. Pour le moment, seul spot qui etait deja gere avec git a ete installe.
J'ai egalement installe une interface gitweb qui permet d'acceder en lecture aux depots qui sont publics. https://git.lrde.org), donc spot.
Pour trac, il faut d'abord mettre a jour le serveur correspondant, vu que le greffon pour git reclame python2.5, ce qui n'etait pas le cas de trac, meme mis a jour (v0.11).
L'acces au serveur doit s'effectuer via ssh git@git.lrde.org ou alors via https pour un git clone uniquement. Il faut donc installer des clefs ssh pour tout ceux qui doivent acceder aux depots en ecriture.
Alexandre Duret-Lutz wrote:
"VO" == Vincent Ordy ordy@lrde.epita.fr writes:
VO> Par contre, si on fait comme ça, je m'écrirai au moins pour moi un VO> hook pour vérifier que la liste des entrées dans le ChangeLog VO> correspond à celles des fichiers modifiés.
Ça permettrait entre autre de détecter des oublis de "git add".
VO> J'avais vu un post d'Akim pour demander à avoir un serveur git au VO> labo: ça en est où ?
Djo est en train d'installer ça ; c'est pour bientôt.
Geoffroy Fouquier geoffroy.fouquier@lrde.epita.fr writes:
J'ai installe un serveur (git.lrde.org) accessible depuis l'interieur et l'exterieur. Pour le moment, seul spot qui etait deja gere avec git a ete installe.
J'ai egalement installe une interface gitweb qui permet d'acceder en lecture aux depots qui sont publics. https://git.lrde.org), donc spot.
Pour trac, il faut d'abord mettre a jour le serveur correspondant, vu que le greffon pour git reclame python2.5, ce qui n'etait pas le cas de trac, meme mis a jour (v0.11).
L'acces au serveur doit s'effectuer via ssh git@git.lrde.org ou alors via https pour un git clone uniquement. Il faut donc installer des clefs ssh pour tout ceux qui doivent acceder aux depots en ecriture.
Classe ! :) Il faut qu'on convertisse les dépôt Subversion, et qu'on se mettre d'accord sur la façon dont on travaille (pour chaque projet).
Roland Levillain wrote:
Classe ! :) Il faut qu'on convertisse les dépôt Subversion, et qu'on se mettre d'accord sur la façon dont on travaille (pour chaque projet).
je regle des details, je voudrais aussi que trac fonctionne, apres pas de soucis, mais comme Alexandre l'a fait remarquer, les dependances sur share risquent de poser probleme.
Geoffroy Fouquier geoffroy.fouquier@lrde.epita.fr writes:
Roland Levillain wrote:
Classe ! :) Il faut qu'on convertisse les dépôt Subversion, et qu'on se mettre d'accord sur la façon dont on travaille (pour chaque projet).
je regle des details, je voudrais aussi que trac fonctionne, apres pas de soucis, mais comme Alexandre l'a fait remarquer, les dependances sur share risquent de poser probleme.
Il faut qu'on convertisse lrde-publis/trunk/share/ en un dépôt Git autonome, que lui puisse intégrer dans d'autre projets (eux-même « engittés ») avec `git submodule'. Et mettre à jour les scripts de share/bin/.
Idem pour argp/trunk/ vis-à-vis de Tiger et Vaucanson.
Roland Levillain roland@lrde.epita.fr writes:
Geoffroy Fouquier geoffroy.fouquier@lrde.epita.fr writes:
Roland Levillain wrote:
Classe ! :) Il faut qu'on convertisse les dépôt Subversion, et qu'on se mettre d'accord sur la façon dont on travaille (pour chaque projet).
je regle des details, je voudrais aussi que trac fonctionne, apres pas de soucis, mais comme Alexandre l'a fait remarquer, les dependances sur share risquent de poser probleme.
Il faut qu'on convertisse lrde-publis/trunk/share/ en un dépôt Git autonome,
Au passage, j'ai déjà fait ce genre de choses (extraire toutes les révisions SVN d'un sous-répertoire donné, pour les intégrer dans un autre dépôt SVN). Je peux filer un coup de main au besoin.
Roland Levillain wrote:
Au passage, j'ai déjà fait ce genre de choses (extraire toutes les révisions SVN d'un sous-répertoire donné, pour les intégrer dans un autre dépôt SVN). Je peux filer un coup de main au besoin.
je termine la mise en place, le demon git puis trac, et ensuite nous pourrons faire la transition. Et oui, si tu sais faire cela, alors ce sera d'une grande aide. Merci.
le demon fonctionne, et trac aussi, j'ai cree un trac pour spot : https://trac.lrde.org/spot (il y a quelques erreurs encore mais pas tres importante)
nous avons donc un acces public aux depots git satisfaisant, et nous pouvons commencer une transition.
- vous pouvez faire votre propre transition et me transmettre le depot .git (comme spot). A ce moment la, je me charge juste d'ajouter les droits et l'export public si necessaire
- si vous souhaitez en profiter pour nettoyer le depot (comme Alexandre souhaite le faire pour vaucanson), je cree un depot vide avec les droits. Cela concerne en particulier la gestion des branches de svn qui sont transformees en tag sous git avec une transition normale. NB : j'ai cree le depot vide vaucanson avec les permissions
- pour les depots lies a 'share', il faut commencer par creer le depot git 'share' (Roland :-))
- sinon je peux faire une transition, je n'ai pas encore regarder comment ca fonctionne tres en detail.
Pour les utilisateurs, n'oubliez pas que tout les exterieurs doient envoyer une clef ssh pour pouvoir faire des mises a jour du depot. Je vais dupliquer les groupes tels qu'ils etaient dans la configuration de svn, mais ces utilisateurs n'auront plus acces sans clef.
Geoffroy Fouquier wrote:
Roland Levillain wrote:
Au passage, j'ai déjà fait ce genre de choses (extraire toutes les révisions SVN d'un sous-répertoire donné, pour les intégrer dans un autre dépôt SVN). Je peux filer un coup de main au besoin.
je termine la mise en place, le demon git puis trac, et ensuite nous pourrons faire la transition. Et oui, si tu sais faire cela, alors ce sera d'une grande aide. Merci.
Geoffroy Fouquier geoffroy.fouquier@lrde.epita.fr writes:
[...]
- pour les depots lies a 'share', il faut commencer par creer le depot
git 'share' (Roland :-))
Je vais créer ça ASAP. À votre avis, pour éviter les désynchronisations entre SVN share/ et le futur Git share/, doit-on éviter/interdire les commits vers SVN share/ à partir de maintenant ?
Roland Levillain wrote:
Je vais créer ça ASAP. À votre avis, pour éviter les désynchronisations entre SVN share/ et le futur Git share/, doit-on éviter/interdire les commits vers SVN share/ à partir de maintenant ?
A qui poses-tu la question ? :) Je peux passer 'share' en lecture seule sur svn sur demande
Geoffroy Fouquier geoffroy.fouquier@lrde.epita.fr writes:
Roland Levillain wrote:
Je vais créer ça ASAP. À votre avis, pour éviter les désynchronisations entre SVN share/ et le futur Git share/, doit-on éviter/interdire les commits vers SVN share/ à partir de maintenant ?
A qui poses-tu la question ? :)
Un peu à tout le monde, en fait. ;) Notamment, aux utilisateurs de share/.
Je peux passer 'share' en lecture seule sur svn sur demande
Éventuellement ; le truc, c'est que je sais que nous sommes plusieurs à y écrire régulièrement en ce moment, notamment pour mettre à jour les bibliographies (c'est une période d'écriture de papiers). Je propose qu'on garde share/ dans SVN jusqu'à la fin du mois, et qu'on le gèle en avril pour le giter.
Geoffroy Fouquier geoffroy.fouquier@lrde.epita.fr writes:
le demon fonctionne, et trac aussi, j'ai cree un trac pour spot : https://trac.lrde.org/spot (il y a quelques erreurs encore mais pas tres importante)
nous avons donc un acces public aux depots git satisfaisant, et nous pouvons commencer une transition.
- vous pouvez faire votre propre transition et me transmettre le depot
.git (comme spot). A ce moment la, je me charge juste d'ajouter les droits et l'export public si necessaire
- si vous souhaitez en profiter pour nettoyer le depot (comme Alexandre
souhaite le faire pour vaucanson), je cree un depot vide avec les droits. Cela concerne en particulier la gestion des branches de svn qui sont transformees en tag sous git avec une transition normale. NB : j'ai cree le depot vide vaucanson avec les permissions
- pour les depots lies a 'share', il faut commencer par creer le depot
git 'share' (Roland :-))
J'ai maintenant un script qui fait ça. Il me manque la conversion des propriétés Subversion (notamment svn:ignore et svn:executable) en leur équivalent Git, mais ça devrait arriver assez vite.
Pour l'instant, j'ai testé les différentes parties du script à la main, mais j'aimerais bien faire un test complet et automatique sur goa (pour des raisons de simplicité car svnadmin/svndumpfilter ne savent pas travailler avec des URL). Geoffroy, est-ce que tu pourrais installer git-svn sur goa pour que je puisse faire un essai.
Le script génère en tant qu'effet de bord une carte des révisions SVN de share vers les hashes de Git. On pourra donc à court terme en tirer un script qui permettra de convertir les propriétés `svn-external: share' en sous-modules Git (youpi). Il faudra qu'on pense à convertir de la même manière les autres externals (comme argp pour tc, par ex.).
Dans les autres bonnes nouvelles, j'ai réussi à convertir le vieu dépot PRCS d'Olena (qui contient les révisions du projet jusqu'à la version 0.11) vers Git. Ce qui est cool, puisque cela nous permettra au final d'avoir un unique dépôt Git avec les travail des dépôt PRCS et Subversion. Il faut que j'améliore prcs2git (qui n'est pas de moi), car les messages de commit sont assez sales, et les auteurs/commiters ne sont pas bien préservés.
Je m'attaque à la conversion du dépôt Subversion d'Olena la semaine prochaine, ainsi qu'a la rédaction d'un petit texte pour expliquer comment nous devr(i)ons travailler après la migration (branche, rédaction des messages de commit, génération de ChangeLog, système d'envoi d'e-mails automatique ou pas, etc.).
Roland Levillain roland@lrde.epita.fr writes:
Geoffroy Fouquier geoffroy.fouquier@lrde.epita.fr writes:
[...]
- pour les depots lies a 'share', il faut commencer par creer le depot
git 'share' (Roland :-))
J'ai maintenant un script qui fait ça. Il me manque la conversion des propriétés Subversion (notamment svn:ignore et svn:executable) en leur équivalent Git, mais ça devrait arriver assez vite.
Pour l'instant, j'ai testé les différentes parties du script à la main, mais j'aimerais bien faire un test complet et automatique sur goa (pour des raisons de simplicité car svnadmin/svndumpfilter ne savent pas travailler avec des URL). Geoffroy, est-ce que tu pourrais installer git-svn sur goa pour que je puisse faire un essai.
J'oubliais : si ça fonctionne bien, on pourra geler (rendre en lecture seule) le répertoire share/ de lrde-publis comme tu le proposais, pour éviter les commits désynchronisés.
Il faudra aussi pense à ce qu'on veut faire de lrde-publis si on décide de le convertir (tout ou partie) à Git (un seul dépot ou plusieurs).
J'oubliais : si ça fonctionne bien, on pourra geler (rendre en lecture seule) le répertoire share/ de lrde-publis comme tu le proposais, pour éviter les commits désynchronisés.
c'est possible de faire cela
Il faudra aussi pense à ce qu'on veut faire de lrde-publis si on décide de le convertir (tout ou partie) à Git (un seul dépot ou plusieurs).
je reste pour le decouper en tranche, quelque soit les tranches, vu la taille.
Geoffroy Fouquier geoffroy.fouquier@lrde.epita.fr writes:
[...]
Il faudra aussi pense à ce qu'on veut faire de lrde-publis si on décide de le convertir (tout ou partie) à Git (un seul dépot ou plusieurs).
je reste pour le decouper en tranche, quelque soit les tranches, vu la taille.
Ok. On va regarder ça ASAP. Peut-être qu'on peut regrouper les répertoires par projet/thème par exemple.
Roland Levillain roland@lrde.epita.fr writes:
Roland Levillain roland@lrde.epita.fr writes:
Geoffroy Fouquier geoffroy.fouquier@lrde.epita.fr writes:
[...]
- pour les depots lies a 'share', il faut commencer par creer le depot
git 'share' (Roland :-))
J'ai maintenant un script qui fait ça. Il me manque la conversion des propriétés Subversion (notamment svn:ignore et svn:executable) en leur équivalent Git, mais ça devrait arriver assez vite.
Pour l'instant, j'ai testé les différentes parties du script à la main, mais j'aimerais bien faire un test complet et automatique sur goa (pour des raisons de simplicité car svnadmin/svndumpfilter ne savent pas travailler avec des URL). Geoffroy, est-ce que tu pourrais installer git-svn sur goa pour que je puisse faire un essai.
J'oubliais : si ça fonctionne bien, on pourra geler (rendre en lecture seule) le répertoire share/ de lrde-publis comme tu le proposais, pour éviter les commits désynchronisés.
Salut Geoffroy,
Je viens de convertir share/ à Git (il est dans le dépôt lrde-publis-share).
Peux-tu interdire l'accès en écriture sur le répertoire share/ du dépôt Subversion `lrde-publis' (mais conserver l'accès en lecture) ? Merci d'avance.
Roland
Quoting "Roland Levillain" roland@lrde.epita.fr:
Peux-tu interdire l'accès en écriture sur le répertoire share/ du dépôt Subversion `lrde-publis' (mais conserver l'accès en lecture) ? Merci d'avance.
c'est bon
Roland
"Geoffroy Fouquier" Geoffroy.fouquier@lrde.epita.fr writes:
Quoting "Roland Levillain" roland@lrde.epita.fr:
Peux-tu interdire l'accès en écriture sur le répertoire share/ du dépôt Subversion `lrde-publis' (mais conserver l'accès en lecture) ? Merci d'avance.
c'est bon
Merci Djo !
Roland Levillain roland@lrde.epita.fr writes:
"Geoffroy Fouquier" Geoffroy.fouquier@lrde.epita.fr writes:
Quoting "Roland Levillain" roland@lrde.epita.fr:
Peux-tu interdire l'accès en écriture sur le répertoire share/ du dépôt Subversion `lrde-publis' (mais conserver l'accès en lecture) ? Merci d'avance.
c'est bon
Merci Djo !
En fait, les étudiants, qui sont en train d'écrire leur rapport (dans un dépôt SVN qui dépend de share/) ont besoin d'aller écrire dans share/, donc ce gel est prématuré. Désolé. :( Est-ce que tu pourrais redonner les permissions en écriture sur lrde-publis/trunk/share/ comme avant, le temps qu'on trouve une autre solution ? Merci d'avance.
Roland
Quoting "Roland Levillain" roland@lrde.epita.fr:
En fait, les étudiants, qui sont en train d'écrire leur rapport (dans un dépôt SVN qui dépend de share/) ont besoin d'aller écrire dans share/, donc ce gel est prématuré. Désolé. :( Est-ce que tu pourrais redonner les permissions en écriture sur lrde-publis/trunk/share/ comme avant, le temps qu'on trouve une autre solution ? Merci d'avance.
c'est fait
Geoffroy Fouquier geoffroy.fouquier@lrde.epita.fr writes:
Roland Levillain wrote:
Geoffroy, est-ce que tu pourrais installer git-svn sur goa pour que je puisse faire un essai.
c'est fait
Merci ! Je vais tester ça.
Dixit Geoffroy Fouquier :
J'ai installe un serveur (git.lrde.org) accessible depuis l'interieur et l'exterieur. Pour le moment, seul spot qui etait deja gere avec git a ete installe.
cool, y'a plus qu'à mettre svn au feu :)
L'acces au serveur doit s'effectuer via ssh git@git.lrde.org ou alors via https pour un git clone uniquement. Il faut donc installer des clefs ssh pour tout ceux qui doivent acceder aux depots en ecriture.
Tous les permanents pour commencer. Tu dois déjà avoir un bon nombre de clef dans leur HOME. Sinon, pour les paranos comme moi, voici ma clef
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArLaNiEgx8SRAjRRWEQ9jKeTNqhobH8kwsI2xyP0zHcKMjMh047mEbsXTReFKNrWIlvYZAtOmBUTFuznN0tOmukg4fBMkjOu9gGKu0HnlKnrLPa8nj2bYbGqIMks1/fO6fhwLjZW2IkHDV8jgDBbdysIz62gqjvF/c/vMmrr1iQU7G0Tsq5E+PjEZX65pH+6LLnmb9RlCqU4wV8PyB+Qy/R6m1p6TekVuDSW9uLiPoHWI4AEKiMbC47lqAHuQmpgAiRS57CydgqS3Rx9T3AF9lje80sseI2WFgZX9qlxGpZ+ER0onv4faM1nnHAH7lu1XhlGwdIPqwD9/uj1nv4+lMQ== ricou@hermes.altribe.org
Olivier Ricou wrote:
Dixit Geoffroy Fouquier :
J'ai installe un serveur (git.lrde.org) accessible depuis l'interieur et l'exterieur. Pour le moment, seul spot qui etait deja gere avec git a ete installe.
cool, y'a plus qu'à mettre svn au feu :)
je laisse les proprietaires de chaque paquet en decider
L'acces au serveur doit s'effectuer via ssh git@git.lrde.org ou alors via https pour un git clone uniquement. Il faut donc installer des clefs ssh pour tout ceux qui doivent acceder aux depots en ecriture.
Tous les permanents pour commencer. Tu dois déjà avoir un bon nombre de clef dans leur HOME. Sinon, pour les paranos comme moi, voici ma clef
je prefere qu'un message me soit envoye et ne pas aller les prendre sur les comptes. Elle doivent etre dans un fichier login.pub. Merci. Ta clef a ete installee.
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArLaNiEgx8SRAjRRWEQ9jKeTNqhobH8kwsI2xyP0zHcKMjMh047mEbsXTReFKNrWIlvYZAtOmBUTFuznN0tOmukg4fBMkjOu9gGKu0HnlKnrLPa8nj2bYbGqIMks1/fO6fhwLjZW2IkHDV8jgDBbdysIz62gqjvF/c/vMmrr1iQU7G0Tsq5E+PjEZX65pH+6LLnmb9RlCqU4wV8PyB+Qy/R6m1p6TekVuDSW9uLiPoHWI4AEKiMbC47lqAHuQmpgAiRS57CydgqS3Rx9T3AF9lje80sseI2WFgZX9qlxGpZ+ER0onv4faM1nnHAH7lu1XhlGwdIPqwD9/uj1nv4+lMQ== ricou@hermes.altribe.org
Geoffroy Fouquier écrivait:
je prefere qu'un message me soit envoye et ne pas aller les prendre sur les comptes. Elle doivent etre dans un fichier login.pub.
Done.
Geoffroy Fouquier geoffroy.fouquier@lrde.epita.fr writes:
Olivier Ricou wrote:
Dixit Geoffroy Fouquier :
J'ai installe un serveur (git.lrde.org) accessible depuis l'interieur et l'exterieur. Pour le moment, seul spot qui etait deja gere avec git a ete installe.
cool, y'a plus qu'à mettre svn au feu :)
je laisse les proprietaires de chaque paquet en decider
Si tout le monde est à l'aise avec Git, pas de problème. Sinon, je pense que c'est dommage de sacrifier la fonctionnalité et l'efficacité à la mode et à l'emphase sécuritaire.
Je rappelle que dans l'intervalle, git-svn est un très bon intermédiaire qui permet de lisser la courbe d'apprentissage.
Geoffroy Fouquier wrote:
je prefere qu'un message me soit envoye et ne pas aller les prendre sur les comptes. Elle doivent etre dans un fichier login.pub. Merci. Ta clef a ete installee.
je precise : envoyer moi un message, avec en attachement un fichier contenant la clef nomme login.pub ou login est *votre* login sur le reseau.
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.
Roland Levillain wrote:
Vincent Ordy ordy@lrde.epita.fr writes:
"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.
On est plusieurs à avoir testé le plugin en question. Il ne marche pas. Jérôme vient juste de me dire qu'il a fait des corrections dessus pour qu'il commence à marcher.
Modifier un historique déjà publié fait justement partie des mauvaises pratiques.
Ça dépend du workflow que tu as choisi. Sur les branches principales, c'est toujours mal.
Si tu crées un branche personnelle sur le serveur pour toujours avoir une backup centralisée de ton travail en cours et commencer à avoir des reviews sans que tout le monde se batte avec des remotes sur les branches des autres développeurs, ça arrive forcément (ne serait-ce que pour faire un rebase avant de demander au mainteneur de merger : une bonne pratique veut qu'on ait un historique le plus linéaire possible pour qu'il soit possible d'utiliser git bisect). Il faut juste bien se mettre d'accord pour que les autres développeurs ne touchent pas à ta branche et quelquefois ils peuvent avoir à faire un reset --hard sur le dernier SHA1.
Vincent Ordy ordy@lrde.epita.fr writes:
Roland Levillain wrote:
Vincent Ordy ordy@lrde.epita.fr writes:
"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.
On est plusieurs à avoir testé le plugin en question. Il ne marche pas. Jérôme vient juste de me dire qu'il a fait des corrections dessus pour qu'il commence à marcher.
Mauvais outil, changer outil.
J'ai rien contre Vim mais Emacs contient quand même des fonctionnalités bien utiles (ne serait-ce que pour gérer les ChangeLogs, les biblio, etc.).
Modifier un historique déjà publié fait justement partie des mauvaises pratiques.
Ça dépend du workflow que tu as choisi. Sur les branches principales, c'est toujours mal.
Si tu crées un branche personnelle sur le serveur pour toujours avoir une backup centralisée de ton travail en cours et commencer à avoir des reviews sans que tout le monde se batte avec des remotes sur les branches des autres développeurs, ça arrive forcément (ne serait-ce que pour faire un rebase avant de demander au mainteneur de merger : une bonne pratique veut qu'on ait un historique le plus linéaire possible pour qu'il soit possible d'utiliser git bisect).
Ça dépend effectivement du workflow : dès fois, on a envie de faire des merges de feature branch, aussi.
Il faut juste bien se mettre d'accord pour que les autres développeurs ne touchent pas à ta branche et quelquefois ils peuvent avoir à faire un reset --hard sur le dernier SHA1.
Oui.
Alexandre Duret-Lutz wrote:
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.
Je viens d'avoir un "problème" avec cette méthode. Je viens de recevoir par mail plusieurs patch extérieurs à appliquer. J'ai donc utilisé git-am pour garder les messages et l'auteur de commit. Mais il n'y avait pas de modif du ChangeLog dans les patch.
Résultat : * soit modifier manuellement les patch reçus ; * soit git rebase -i pour éditer tous les patchs à la main après les avoir appliqués ; * soit appliquer les patchs un par un, copier/coller le message de commit et perdre l'auteur du commit.
Je crois qu'il n'y a pas de méthode parfaite avec ces $@#{) de ChangeLog :(
Vincent Ordy ordy@lrde.epita.fr writes:
Alexandre Duret-Lutz wrote:
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.
Je viens d'avoir un "problème" avec cette méthode. Je viens de recevoir par mail plusieurs patch extérieurs à appliquer. J'ai donc utilisé git-am pour garder les messages et l'auteur de commit. Mais il n'y avait pas de modif du ChangeLog dans les patch.
Résultat :
- soit modifier manuellement les patch reçus ;
- soit git rebase -i pour éditer tous les patchs à la main après les
avoir appliqués ;
- soit appliquer les patchs un par un, copier/coller le message de
commit et perdre l'auteur du commit.
Je crois qu'il n'y a pas de méthode parfaite avec ces $@#{) de ChangeLog :(
Si, imposer que l'auteur fournisse les entrées de ChangeLogs qui faisaient défaut.
Alexandre Duret-Lutz adl@lrde.epita.fr writes:
Quelques critiques...
:)
[...]
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.
C'est ma solution préférée, après celle qui vient.
- 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.
C'est le meilleur compromis je trouve : un script qui génère un ChangeLog à partir des messages du dépôt, et qui note quelque part quels commits ont été pris en compte.
1. ça permet d'avoir un vrai fichier ChangeLog dans le dépôt, qu'on peut lire avec un vrai éditeur (pas forcément toujours à jour, mais c'est pas très grave) ;
2. ça évite le problème de duplication (et de divergence !) entre messages Git et entrées de ChangeLog ;
3. ça permet de *corriger* les ChangeLog ; dans les solutions où tout est généré, on a l'air malin lorsque des entrées sont vides, comportent des fautes ou sont incomplète. Au moins, on se donne une chance de pouvoir corriger. Rappel : on ne veut bien sûr pas modifier le dépôt (publié), puisque c'est une pratique à proscrire.
Comme on garde sous le coude (dans le dépôt) le dernier commit pris en compte par le ChangeLog, la prochaine fois qu'on le régénèrera, on ne lui ajoutera que les entrées nouvelles.
C'est vraiment la solution que je préfère, et que j'ai envie d'utiliser dans Olena et Tiger.
- ne plus écrire de ChangeLog et ne même plus les générer (c'est
l'approche de Linux).
Arg !
Thierry GERAUD wrote:
question bête :
je suis un nouvel utilisateur de git, je veux pousser et que ça me mâche le travail + envoie un joli mail à la destination qui va bien. je fais quoi concrètement ?
En ce moment j'utilise un dépôt git qui est configuré pour envoyer automatique des mails à chaque 'push' et il n'y a rien à faire sur le client. C'est très pratique.
C'est assez simple à configurer sur le serveur, c'est ADL qui m'avait indiqué comment faire. Ça se passe dans .git/hooks/post-receive où il faut décommencer la ligne avec le filtre post-reveive-email.
-
Alexandre Duret-Lutz -
Didier Verna -
Geoffroy Fouquier -
Olivier Ricou -
Roland Levillain -
Thierry GERAUD -
Vincent Ordy -
yabo