Git/GitLab : merge request et squash pour duniter-v2s

Nodes Duniter-v2s
1

OK :slight_smile:

Tu peux merger en local, lors du commit de merge Git te permet de choisir le nom du commit.

Oui mais avec le squash tu rends plus difficile la relecture des contributeurs qui maîtrisent Git, ceux-là même que vise un dépôt tel que duniter-v2s. Personnellement je fais toutes mes revues de code dans mon IDE, j’ai de bonnes raisons de le faire, je peux détailler si tu veux.

Oui mais pas dans Git, du coup l’IDE devient aveugle. Quand je me poserait la question de savoir d’où provient une ligne de code, je tomberai sur le commit de squash où je ne verrai plus du tout le contexte de la modification (ni le nom du commit, ni les autres modifications qui étaient liées à ce moment-là). Et jongler avec GitLab pendant une revue c’est juste l’enfer.

S’il te plaît, réfléchis-y davantage, je pense vraiment que ce workflow est pénalisant pour le dépôt duniter-v2s.

2

Je ne veux surtout pas avoir Ă  merger en local:

  1. Ça forcera à garder le droit de push direct sur master, que je ne veux pas garder à terme.
  2. C’est moins fluide, ça fait plus de boulot coté mainteneur, je veux pouvoir tout faire dans l’UI du gitlab pour gérer une contribution.

Je ne pense pas, c’est le workflow qu’on utilise au boulot, et utilisé par parity pour substrate lui-même, et à l’usage je n’ai pa ressenti de gène pour reviewer, au contraire c’est plus facile de reviewer car le squash permet d’interdire les force push :slight_smile:

Un commit = 1 MR, caque commit sur la branche principale contient le numéro de la MR dans son nom, ce qui permet de retrouver le contexte. En plus, chaque MR à généralement une issue associée.

Je pense l’inverse, l’ancien workflow était beaucoup plus pénalisant, je l’ai constaté quand j’ai du géré les contributions de @vincentux et @HugoTrentesaux.

je suis également beaucoup plus productif avec ce workflow, désolé, mais je ne compte pas revenir en arrière alors que j’ai pour la 1ère fois de ma vie la sensation d’avoir enfin trouvé un workflow git qui me conviens pleinement, il va falloir t’adapter :slight_smile:

EDIT: @cgeek il y bien une solution pour tes besoins de review: ne pas supprimer la branche de dev sur le remote lors du merge.

1 Like
3

Le fait de ne pas supprimer la branche de dev distante lors du merge est déjà une aide, en effet :+1:

Mais bon on perd toujours de l’information. Tant pis, si c’est ce qui te convient le mieux et que je suis le seul que ça gêne, oui je vais m’adapter.

4

Si c’est le mainteneur qui fait le squash, et que ça fusionne les commits à ce moment là, ça veux dire que le nouveau commit est au nom du mainteneur et non à celui de l’auteur du code proposé au merge c’est bien ça ?

Si oui, je comprends que dans un contexte d’entreprise ça ne pose pas trop de problème (la propriété du code est à l’entreprise de toute manière), mais dans le cadre d’un projet libre, identifier les auteur de chaque bout de code me semble bénéfique :

  • pour faire un git blame et voir Ă  qui s’adresser si on est perdu avec un bout de code legacy
  • pour faire des statistiques de contribution au code et en dĂ©duire la robustesse de la communautĂ© face au dĂ©part du mainteneur principal (le bus factor en gros)
  • pour permettre certains modèles de rĂ©munĂ©ration voir de gouvernance (mais pas sĂ»r qu’ils soient souhaitables)

En dehors du changement supposé d’attribution du code au mainteneur plutôt qu’à l’auteur, je ne vois pas de souci avec la simplification de l’historique de commit de la branche principal (main ou master)

5

Non c’est gitlab qui fait le squash, le commit généré est au nom de tout les contributeurs de la MR :slight_smile:

6

Ok, donc tant qu’on ne vise pas une tracabilité à base de commit signé cryptographiquement par l’auteur, ça marche :slight_smile:

1 Like