Re: Environnement de dev avec Git

Salut

> Pour faciliter le passage à Git pour tous, ça serait bien qu'on réfléchisse à un "dossier Git" qu'on pourrait rédiger sur Contrib. Peut-être, même sûrement qu'il existe déjà des contributions qu'on pourrait réorganiser voire compiler.

Excellente idée :)

> Dans ce cadre, j'ai regardé un peu le fichier .gitignore.
> J'avais d'ailleurs rajouté l'exclusion du .idea de PHPStorms dans le .gitignore de SPIP ce qui est finalement une erreur de stratégie.

Pas sûr. Pour ma part je dirais plutôt bonne idée.

> Dans le fichier de chaque repo on ne devrait avoir que ce qui concerne les fichiers du repo et pas les fichiers ou répertoires du style .DS_store ou .idea qui devraient être dans un .gitignore_global.
> D'où ne devrait-on pas créer et fournir un .gitgnore_global sur la forge euh zone dans _outils_ ou à la racine et dépouiller en conséquence le .gitgnore de SPIP ?

En fait il n'es pas possible d'imposer une .gitignore global ou du
moins à s'attendre qu'il soit réellement utilisé. Au niveau d'un dépôt
git on ne peut qu'avoir la garantie de l'application du .gitignore
local.
Bien qu'on peut cascader les règles (
https://git-scm.com/docs/gitignore ) et donc avoir avoir des règles
globales ( https://help.github.com/en/articles/ignoring-files#create-a-global-gitignore
), ll n'y a aucun moyen d'en connaître leurs existences/usages.
Par exemple, dans un projet git si le .gitignore n'interdit pas .idea
il sera impossible de bloquer des commits embarquant ce type de
fichiers.

Je dirais qu'il est plus pertinent de proposer des modèles complets de
gitignore adaptés aux projets SPIP. Il n'est pas problématique d'avoir
des règles communes (je dirais même conseillées)
Un site de référence bien pratique pour ces modèles est http://gitignore.io/

On pourrait en proposer selon l'usage type des contributions SPIP. En
l'état j'en identifie au moins 3 :
* le type core (qui concerne spip , ecrire, prive )
* de type plugins (plugins et extensions)
* de type squelettes
* autres

De fait ces fichiers peuvent avoir des règles communes comme celles relatives :
* aux IDE comme .idea .vscode, *.*~, ...
* aux OS comme .DS_store , ...
* aux appels des bibliothèques externe (vendor/ , ....)

Il est aussi possible d'ignorer les règles comme celles des OS ou IDE
comme tu le proposes si on renvoi vers un modèle qui les concatène,
par exemple : http://gitignore.io/api/linux,macos,windows,phpstorm+all,visualstudiocode

Et on peut alors se concentrer aux cas par cas selon leur typologie.
Comme pour les squelettes avec la gestion de css/sass/less/... et les
outils gulp/... ou bien aux plugins avec des lib externes. Je n'ai pas
assez de recul pour ma part pour identifier ces spécificités.


> En outre, je vois que dans le .gitignore de SPIP il y a pleins de lignes qui se répètent comme
>
> IMG/.htaccess
> config/.htaccess
> ecrire/.htaccess
>
> Normalement on pourrait écrire
> **/.htaccess
> il me semble non ? Et ainsi réduire énormément le fichier.

Oui il est possible de condenser certaines règles. Je dirais que c'est
une histoire de goût car à ma connaissance il n'y aura pas de
différence dans le comportement de git.
Pour ma part on peut tout à fait garder ce genre de répétitions si
cela permet de faire comprendre (indirectement) les méandres du
projet. Dans le premier cas on comprend que des .htaccess devraient se
trouver à divers endroits précis. Dans le second cas on ne peut le
deviner (sauf à lire une documentation annexe ou le code d'un projet
existant).

> Je me trompe ?

Non :)
Comme tu peux le voir c'est pas mal une histoire de goût. Être
exhaustif ou non selon les habitudes/confiances globales de la
communauté.
Pour ma part je serais plutôt exhaustif.


Km