Les projets git pour SPIP
▻http://git.spip.org/gitphp
▻https://twitter.com/webelys/status/469494198459457537
Merci @azerttyu ;-)
Les projets git pour SPIP
▻http://git.spip.org/gitphp
▻https://twitter.com/webelys/status/469494198459457537
Merci @azerttyu ;-)
Oui c’est un scandale, le contributeur principal ne respecte pas les règles de commit :
–* ▻http://zone.spip.org/trac/spip-zone/browser/_plugins_/crayons
Il faut à minima un #trunk pour avoir du #git
On peut supposer que c’est lié à l’utilisation de l’outil de migration #git-svn qui peut faire des choses très sympa en récupération de l’historique avec l’une des options ’’’—stdlayout’’’ ou ’’’-T’’’ mais bon, ça peut être aussi autre chose, je fais que supposer... c’est souvent long à procéder, et le résultat n’est pas toujours à la hauteur, surtout quand les dev n’ont pas utilisé svn « comme il faut » pour gérer tags et branches ...
ô toi qui aime l’anglais, lis donc ça : ▻https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
Yop
@fil tout #VCS recommande à minima la logique trunk/branches/tags, certains plugins suivent cette recommandation, d’autres non.
Il est parfois bon d’être rationnel et si possible de suivre les bonnes pratiques.
Autre point où copierons nous la branches créée depuis git dans la version svn ?
@james #git-svn n’est pas utilisé car ne fait pas le boulot voulu. Le « layout » utilisé permet d’être bijectif :
on peut contribuer indifféremment sur la copie git ou svn c’est pareil.
Question piège : à quoi ressemblerait le « layout » pour les plugins core ? :)
Est ce qu’on doit vraiment en passer par là, je dirais oui car il nous faut être cohérent pour ne pas se mettre des traverses dans les pieds, on a assez de bâtons pour le moment.
Je regarde pour que ce soit le plus transparent possible même pour ces plugins, mais ce n’est pas trivial.