Git conventions: proofreading
Merge request reports
Activity
assigned to @librelois
@moul Je ne veut pas de type [mod], c'est trop prêt du type [ref]. Ta définition de [mod] correspond déjà a des types de commit existant selon le type d'amélioration :
Si c'est une amélioration fonctionnelle c'est [feat].
Si c'est une amélioration des performances c'est [opti].
Si c'est une amélioration de la qualité/lisibilité/maintenabilité du code c'est [ref].[mod] est trop générique et fini inévitablement par être utilisé trop souvent et on perd alors tout l’intérêt des types de commit a la lecture de l'historique.
[enh] fait doublon avec [feat], on peut modifier la définition de [feat] pour préciser que l'amélioration fonctionnelle d'une feature déjà existante rentre dans le cadre de [feat] ;)
EDIT: avant de modifier les conventions du projet la moindre des courtoisies aurai été d'en discuter avec moi par MP ;)
Edited by Éloïs
Je ne veut pas de type [mod], c'est trop prêt du type [ref]. Ta définition de [mod] correspond déjà a des types de commit existant selon le type d'amélioration :
Si c'est une amélioration fonctionnelle c'est [feat].
Si c'est une amélioration des performances c'est [opti].
Si c'est une amélioration de la qualité/lisibilité/maintenabilité du code c'est [ref].Pour moi, une modification c’est plutôt mineur.
Un réfactoring, c’est assez impactant comme modification. On réécrit une fonction, un comportement.
[mod] est trop générique et fini inévitablement par être utilisé trop souvent et on perd alors tout l’intérêt des types de commit a la lecture de l'historique.
Assez d’accord.
[enh] fait doublon avec [feat], on peut modifier la définition de [feat] pour préciser que l'amélioration fonctionnelle d'une feature déjà existante rentre dans le cadre de [feat] ;)
Une feature, c’est une nouvelle fonctionnalité, la résolution de fork par exemple, pas une modification de ce que va afficher la CLI.
Et,
feat, ça me fait trop penser à https://fr.wikipedia.org/wiki/Featuringavant de modifier les conventions du projet la moindre des courtoisies aurai été d'en discuter avec moi par MP ;)
J’ai justement ouvert la discussion ici en proposant mes modifications pour qu’on sache de quoi je parle.
- Ça te pose un problème que ça soit fait en publique ? Ce genre de discussions devrait rester publique pour que les autres contributeurs puissent savoir ce qui se passe.
- Où, c’est plutôt le fait que tu veux m’éviter un effort qui sera perdu ? Sache que ça ne me dérange pas. C’est de la doc pas du code. C’est quand même moins dur à produire.
Pourquoi fermes-tu la MR ? La révision de relecture est pas intéressante ?
Edited by Moul-
Pour moi, une modification c’est plutôt mineur.
Un réfactoring, c’est assez impactant comme modification. On réécrit une fonction, un comportement.
Dans le projets Durs, le type [ref] est utilisé pour tout changement de code qui n'impacte pas le fonctionnel, qu'il soit mineur ou majeur.
Le projet a déjà un historique important, si on s'amuse a changer les conventions a chaque fois qu'un nouveau contributeur viens avec ses habitudes a lui on ne vas plus rien y comprendre dans l'historique. De plus il y a déjà bien assez de type de commit différents, je ne veut pas qu'on en rajoute, je cherche au contraire des moyens de simplifier les conventions, pas de les complexifier.
J'ai fermé la MR car a mon sens les MR ne sont pas faites pour discuter des décisions du projet, normmalement on passe au stade de la MR quand les décisions ont déjà été prises. Si tu souhaite en parler publiquement tu pouvais par exemple ouvrir un ticket proposant de modifier les conventions, ont en aurai discuté dessus :)
Edited by Éloïs added C-documents label
added 4 commits
-
07f20a17...101f305e - 3 commits from branch
dev - 5fd550fc - [doc] conventions git: proofreading
-
07f20a17...101f305e - 3 commits from branch
enabled an automatic merge when the pipeline for 5fd550fc succeeds