Le mail qui arrive sur spip-zone-commit@rezo.net ne reprend pas mon nom comme défini sur la forge mais un pseudo que j'ai dû rentré je ne sais où (et je ne sais pas où pour le coup, donc je suis intéressé pour le changer également ).
Est-il possible de cacher les adresses pour ces commits d'avant la migration ? Si on peut éviter du spam.
Et question liée : Est-il possible de lier ces commits d'avant la migration SVN > GIT à notre nouveau compte git ?
Je pense que c'est mort, car la branche master a été importé après le renommage côté svn.
Le mail qui arrive sur spip-zone-commit@rezo.net ne reprend pas mon nom comme défini sur la forge mais un pseudo que j'ai dû rentré je ne sais où (et je ne sais pas où pour le coup, donc je suis intéressé pour le changer également ).
C'est ta config git qui veut ça, regarde du côté de "git config -l".
Est-il possible de cacher les adresses pour ces commits d'avant la migration ? Si on peut éviter du spam.
Je laisse Camille répondre sur ce point, mais bon ça n'est pas bien grave amha.
Et question liée : Est-il possible de lier ces commits d'avant la migration SVN > GIT à notre nouveau compte git ?
Oui, il faut effectuer "une petite manip" pour ça, cf le point 2 de ce billet de Cedric :
Je pense que c’est mort, car la branche master a été importé après le
renommage côté svn.
Je pense aussi.
Maintenant, si on a accès à de la customisation des pages (à voir quand nicod sera au point dessus) on pourra éventuellement mettre un bouton pour se rendre directement sur la page follow copy de la Zone.
Le mail qui arrive sur spip-zone-commit@rezo.net ne reprend pas mon nom
comme défini sur la forge mais un pseudo que j’ai dû rentré je ne sais
où (et je ne sais pas où pour le coup, donc je suis intéressé pour le
changer également ).
C’est ta config git qui veut ça, regarde du côté de « git config -l ».
Pour rappel le chapitre configuration des articles git : http://blog.smellup.net/spip.php?article87
Sur la forge tu peux aussi changer ton « nom complet » car il est égal à ton pseudo jeanmarie.
1/ Comment voir les commits d'avant le changement d'arborescence en trunk
Cela n'est pas possible. Git considère comme racine le répertoire
trunk du svn. Tout ce qui était ailleurs avant ce répertoire de facto
n'existe pas pour git.
Je pense aussi à un autre truc il est possible dans git de voir la
correspondance du commit svn.
Pour ceci il faut ajouter dans le fichier de configuration les notes subgit :
1/ Comment voir les commits d'avant le changement d'arborescence en trunk
Cela n'est pas possible. Git considère comme racine le répertoire
trunk du svn. Tout ce qui était ailleurs avant ce répertoire de facto
n'existe pas pour git.
Ok.
L'idée d'Eric pour accéder facilement aux anciens commits serait pas mal alors.
2/ Le mail qui arrive sur spip-zone-commit@rezo.net ne reprend pas mon nom [...]
La notification par courriel reprend les informations communiquées
dans le commit
git config user.email / git config user.name
Cela n'a rien à voir avec le compte git ouvert sur la forge.
Effectivement, c'est chez moi
3/ Et question liée : Est-il possible de lier ces commits d'avant la
migration SVN > GIT à notre nouveau compte git ?
Non. La solution de b_b répond pour un cas où l'import se fait hors de
l'écosystème de git.spip.net
Ok.
Et merci pour pour la FAQ, Eric, ça sera très utile !
Je reprends un peu cette discussion car il y a un truc qui me turlupine.
Je m’attendais pas à ce que les commits soient trunkés avant le passage en trunk.
Aussi j’ai préparé les plugins 3.2 qui n’étaient pas en trunk en les passant en trunk.
Je comprends aujourd’hui que ce n’était pas la bonne pratique.
Je me demande, car il est encore temps et comme nous avons un script d’import qui sait le faire, si il ne faudrait pas repérer tous mes derniers commits de ce type, les revert et refaire un import vers Git de la version sans trunk ?
Ca ne doit pas être trop lourd car il y en avait pas des tonnes des plugins “uniques” sans branches ni trunk.
Autre chose quand on parle de branche pour l’import vers Git est ce que des libellés comme svp2010, 2012 ou jenesaispasquoi sont licites et peuvent être importés ?
Je reprends un peu cette discussion car il y a un truc qui me turlupine.
Je m'attendais pas à ce que les commits soient trunkés avant le passage en trunk.
Aussi j'ai préparé les plugins 3.2 qui n'étaient pas en trunk en les passant en trunk.
Je comprends aujourd'hui que ce n'était pas la bonne pratique.
C'est à dire ? J'ai peut être mal expliqué un truc dans la logique d'import.
Je me demande, car il est encore temps et comme nous avons un script d'import qui sait le faire, si il ne faudrait pas repérer tous mes derniers commits de ce type, les revert et refaire un import vers Git de la version sans trunk ?
Ca ne doit pas être trop lourd car il y en avait pas des tonnes des plugins "uniques" sans branches ni trunk.
Le notion de branches et tags dans svn n'est qu'une convention de nommage.
Le script d'import git considère 2 cas de figure :
* un répertoire avec du code (pas de branches, pas de tags, pas de
trunk) dans ce cas ces données sont traitées comme master dans git
(les branches et tags ne seront pas reportées dans svn)
* un répertoire avec au moins un répertoire trunk (et branches/) (et
tags/) dans ce cas est associé le contenu de trunk à master, les
branches/* sont notées comme branches (peut importe leur nom), de même
pour les tags.
Ensuite il est possible de faire comme pour les plugins _core_ qui
sont explosés dans divers répertoire. En gros lors de l'import on dit
quel chemin svn correspond ce qu'on veut mettre dans master, tags et
branches de git.
Notes annexes :
* Pour les tags il est possible de les créer à la volée via le script
* Il est possible dans le cas d'import sans trunk d'imposer des
répertoires externes pour associer branches et tags (un peu comme pour
_core_)
On peut détruire un dépôt et le réimporter sous la base d'un autre modèle.
Oui oui Camille tout ça est très clair pour moi j'ai utilisé les modèle trunk et sans trunk sans problème.
Je parle juste du problème de perte des logs de commit antérieurs au passage en trunk.
Pour certains plugins prenons toto/ qui n'avait pas de trunk j'ai créé un toto/trunk il y a quelques jours.
Donc en l'important avec le modèle zone je n'ai récupéré que les derniers commits depuis le passage en trunk alors que si j'avais pas créé le trunk et l'avait importé avec le modèle zone_mono j'aurais tous les logs.
D'où ma question, pour ces plugins dont le trun a été créé récemment et qui n'ont pas subi de commit depuis, ne serait-il pas judicieux de revert le passage en trunk et de reimporter le plugin sous git à partir de là ?
Si on considère que git devient bien la référence on peut revenir sur
un import avec le modèle mono (Destruction du dépot git, svn revert,
git import mono)
En complément si on veut maintenir (le temps de la transition) le
suivi svn des branches et tags, on doit créer 2 répertoires cibles
dans le svn. Peut importe leur emplacement c'est une convention à
définir.
Ce qui pourrait donner pour le projet toto :
master => /_plugins_/toto/*
branches => /_plugins_/branches/toto/* ou /_branches_/toto/*
tags => /_plugins_/tags/toto/* ou /_tags_/toto/*
Le second cas est plus générique car on ne se préoccupe pas de savoir
dans quel répertoire source se trouve le projet.
Ah oui, je viens de comprendre !
En fait ce problème de trunk n'est un "problème" qu'à cause de la synchronisation Git => SVN car si je prends un plugin sans trunk, que je l'importe sous Git et que je crée une branche Git où subgit va-t-il synchroniser la nouvelle branche ? Tandis que si le trunk existe déjà je suppose qu'on a prédéfini le fait que la branche va se faire à coté du trunk.
C'est ça même si on n'a que trunk de présent coté svn, le système
prend la convention trunk/branches/tags et pas autres choses. Donc si
on commit une branche depuis git, le répertoire branches/ sera créé à
la volée coté svn.
Mais alors pour les plugins qui ont été importés en zone_mono que se passe-t-il si on crée une branche en Git ?
Pour le moment rien il vont être ignorés car on n'a pas défini de conventions.
Si on part par exemple sur :
branches => /_branches_/toto/*
tags => /_tags_/toto/*
On peut le définir par défaut pour l'ensemble des projets mono.
Si on part sur
branches => /_plugins_/branches/toto/*
tags => /_plugins_/tags/toto/*
Le ménage sera un poil plus long car il faudra distinguer la racine
_plugins_/, _squelettes_/ ...
On peut définir n'importe quelle autre convention pour les chemins
svn. Ce ne sont que 2 propositions qui me semble "évidente"
Peut-être qu’il suffit de faire l’import en ciblant le dossier trunk sans l’option « shema standard » pour garder l’historique ?
IE au lieu d’importer _squelettes_/html5up_alpha/ en disant « il y a un trunk et des branche » importer directement _squelettes_/html5up_alpha/trunk ?
On fait l’essai sur ce cas particulier de html5up_alpha pour voir ? (quitte à tester l’import à côté dans un autre projet)
Je prends par exemple le squelettes ahuntsic.
Le dernier commit est le mien pour le passage en trunk.
Sous Git on ne voit que ce commit, pour moi c’est pas terrible.
On peut essayer autrement sur celui-ci.
Cédric je comprends pas bien ce que tu veux faire exactement pour régler ce problème ?
Notes annexes :
* Pour les tags il est possible de les créer à la volée via le script spip-contrib-outils / creer_tags · GitLab
* Il est possible dans le cas d'import sans trunk d'imposer des
répertoires externes pour associer branches et tags (un peu comme pour
_core_)
est-ce que cela ne vaudrait pas le coup de mettre un tel script sous forme de hook de post push ?
).
).
).