Meme sur un projet open source que je contrôle pas, si je sais que je vais casser une partie important de l'architecture/code, je vais commencer par une RFC/RequestForComment avant de me lancer dedans
Bien sûr, c'est ce qu'on veut faire.
Effectivement ici j'adapte mon workflow de travail à l'outil (petit commit régulier, intégrer le plus tôt possible par rapport à un gros commit intégré en mode big bang, ceci afin d'éviter les conflits).
Je ne pense pas que ce soit "ici" que tu adaptes ton mode de travail à l'outil, parce que c'est une façon de travailler raisonnable. Par contre, je pense que ce mode de travail n'est justement pas très adapté à Git, parce qu'il t'impose une grande quantité de travail supplémentaire :
il t'impose de fréquents rebases et merges (parce que tes collaborateurs font pareil), et on sait que Git peut faire vraiment n'importe quoi à ce moment-là, exemples là : https://pijul.org/manual/why_pijul.html. Personnellement, je valorise un peu trop mon temps de travail pour laisser un outil mélanger mes lignes aléatoirement comme ça.
pour la même raison, si tu as un processus de reviews en place, Git ne te permet pas de prévoir manuellement comment le merge va se passer, même s'il n'y a aucun conflit, parce qu'un 3-way merge n'est pas le bon problème à résoudre : sa solution n'est pas unique et dépend de l'algorithme utilisé.
tu vas aussi devoir planifier précisément le travail en amont, pour organiser tes branches. Même si c'est possible au début d'un projet, on sait bien que dans un projet compliqué, un bug peut venir de plein d'endroits différents, et révéler complètement autre chose que ce qui était planifié au départ.
si jamais tu voulais maintenir deux versions d'un projet, la quantité de rebases, merges et rerere nécessaires te découragerait rapidement. J'ai un exemple très concret d'un bibliothèque Rust pour SSH (https://nest.pijul.com/pijul/thrussh), qui a plusieurs versions en parallèle avec presque les mêmes patchs, parce que l'écosystème Rust est en train de migrer entre deux versions d'une bibliothèque fondamentale pour les entrées-sorties asynchrone (Tokio), et qu'il faut pouvoir corriger les bugs sur les deux versions en même temps.
[^] # Re: Sympa
Posté par pmeunier . En réponse au journal Pijul, version 1.0 en approche. Évalué à 5.
Bien sûr, c'est ce qu'on veut faire.
Je ne pense pas que ce soit "ici" que tu adaptes ton mode de travail à l'outil, parce que c'est une façon de travailler raisonnable. Par contre, je pense que ce mode de travail n'est justement pas très adapté à Git, parce qu'il t'impose une grande quantité de travail supplémentaire :
il t'impose de fréquents rebases et merges (parce que tes collaborateurs font pareil), et on sait que Git peut faire vraiment n'importe quoi à ce moment-là, exemples là : https://pijul.org/manual/why_pijul.html. Personnellement, je valorise un peu trop mon temps de travail pour laisser un outil mélanger mes lignes aléatoirement comme ça.
pour la même raison, si tu as un processus de reviews en place, Git ne te permet pas de prévoir manuellement comment le merge va se passer, même s'il n'y a aucun conflit, parce qu'un 3-way merge n'est pas le bon problème à résoudre : sa solution n'est pas unique et dépend de l'algorithme utilisé.
tu vas aussi devoir planifier précisément le travail en amont, pour organiser tes branches. Même si c'est possible au début d'un projet, on sait bien que dans un projet compliqué, un bug peut venir de plein d'endroits différents, et révéler complètement autre chose que ce qui était planifié au départ.
si jamais tu voulais maintenir deux versions d'un projet, la quantité de rebases, merges et rerere nécessaires te découragerait rapidement. J'ai un exemple très concret d'un bibliothèque Rust pour SSH (https://nest.pijul.com/pijul/thrussh), qui a plusieurs versions en parallèle avec presque les mêmes patchs, parce que l'écosystème Rust est en train de migrer entre deux versions d'une bibliothèque fondamentale pour les entrées-sorties asynchrone (Tokio), et qu'il faut pouvoir corriger les bugs sur les deux versions en même temps.
Pijul n'a pas ces contraintes.