commuter des patches (donc réécrire l'historique) ou encore faire des rebase après merge.
La seule raison pour laquelle "c'est considéré comme de mauvaises pratiques", c'est justement parce que Git ne permet pas de le faire proprement !
Gné ? On ne serait pas dans le syndrome du "not done here" ?
Non, mais si ça t'intéresse de comprendre, tu peux reposer la même question sans mépris ;-)
D'autre part il faudrait savoir, entre "tu ne fais pas d'UI" et "not done here". Quand on veut une bonne UI il y a parfois des trucs un peu casse-pieds à faire.
Je n'ai pas posé de question sur la théorie
Non, mais @dfroger en a posé une, je lui ai répondu. Un "workflow" de discussion assez classique à mon avis.
Tiens, je vais commencer. Mon workflow git (assez classique je pense):
Si tu es content avec ton workflow et ton git, c'est très bien, garde-le ! Ça a l'air en effet bien adapté à un gros projet qui roule déjà bien, avec des gens qui comprennent bien le problème qu'ils doivent résoudre, et qui prennent le temps d'organiser leur travail avant de commencer, qui travaillent sur des sous-projets bien délimités à l'avance, qui font rarement d'erreurs, et dont les bugs sont assez "locaux", c'est-à-dire pas trop intriqués les uns avec les autres. Si en plus ils ont le temps de réparer les merges et les rebases qui n'ont pas marché automatiquement, et qu'ils valorisent le respect des contraintes techniques de Git (les dites "bonnes pratiques") plus que leur temps de travail, que demande le peuple ?
Pijul essaie de gérer tous les autres cas, qui correspondent en fait assez bien à mon expérience de programmation et d'écriture d'article. Mon expérience est en fait pire, puisqu'elle est souvent la négation de tous ces trucs-là à la fois !
À savoir des gens qui s'attaquent à un problème inconnu, donc difficile à planifier à l'avance, qui travaillent sur des trucs trop durs pour eux, passent leur temps à devoir refactoriser à mesure qu'ils avancent, et dont la résolution d'un bug (1) soit nécessite de creuser assez profond en touchant à plein de choses (parfois seulement pour tester), (2) soit permet d'arriver dans un nouveau cas qui n'était pas géré, ce qui déclenche un nouveau bug. Et souvent, le temps est limité, soit parce que les gens compétents sur les trucs durs sont trop chers pour leur faire perdre du temps sur Git, soit (dans le cas d'un article) parce qu'il y a une deadline, et qu'on préfère faire des maths que faire du Git.
Il y a un coût caché non-négligeable dans ce type de projet, c'est le coût de changer de contexte. Si je suis en train de faire du code ou d'écrire du LaTeX, ça me demande souvent une concentration importante. Si j'ai à réfléchir à mes branches et mes rebases, et à réparer ce qui casse, je dois me remettre dans le problème après avoir réparé, et ça coûte du temps.
La plupart des problèmes que je rencontre aujourd'hui sont liés au merge, effectivement. Il me semble que la plupart du temps, des patchs sémantiques régleraient le problème, par exemple quand il les patchs concernent du coding style, du refactoring, etc.
Le plus gros problème est que le patch minimal n'est pas unique. Par extension, diff3 a parfois plusieurs choix, ce qui est assez inquiétant, parce que Git peut parfois mélanger des lignes un peu n'importe comment.
Suis-je donc le seul à rencontrer ces problèmes ? Pijul le résout-il ?
Non (de très loin), et oui, à 100%, sans patchs sémantiques.
[^] # Re: Difference Pijul vs Git
Posté par pmeunier . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 10.
La seule raison pour laquelle "c'est considéré comme de mauvaises pratiques", c'est justement parce que Git ne permet pas de le faire proprement !
Non, mais si ça t'intéresse de comprendre, tu peux reposer la même question sans mépris ;-)
D'autre part il faudrait savoir, entre "tu ne fais pas d'UI" et "not done here". Quand on veut une bonne UI il y a parfois des trucs un peu casse-pieds à faire.
Non, mais @dfroger en a posé une, je lui ai répondu. Un "workflow" de discussion assez classique à mon avis.
Si tu es content avec ton workflow et ton git, c'est très bien, garde-le ! Ça a l'air en effet bien adapté à un gros projet qui roule déjà bien, avec des gens qui comprennent bien le problème qu'ils doivent résoudre, et qui prennent le temps d'organiser leur travail avant de commencer, qui travaillent sur des sous-projets bien délimités à l'avance, qui font rarement d'erreurs, et dont les bugs sont assez "locaux", c'est-à-dire pas trop intriqués les uns avec les autres. Si en plus ils ont le temps de réparer les merges et les rebases qui n'ont pas marché automatiquement, et qu'ils valorisent le respect des contraintes techniques de Git (les dites "bonnes pratiques") plus que leur temps de travail, que demande le peuple ?
Pijul essaie de gérer tous les autres cas, qui correspondent en fait assez bien à mon expérience de programmation et d'écriture d'article. Mon expérience est en fait pire, puisqu'elle est souvent la négation de tous ces trucs-là à la fois !
À savoir des gens qui s'attaquent à un problème inconnu, donc difficile à planifier à l'avance, qui travaillent sur des trucs trop durs pour eux, passent leur temps à devoir refactoriser à mesure qu'ils avancent, et dont la résolution d'un bug (1) soit nécessite de creuser assez profond en touchant à plein de choses (parfois seulement pour tester), (2) soit permet d'arriver dans un nouveau cas qui n'était pas géré, ce qui déclenche un nouveau bug. Et souvent, le temps est limité, soit parce que les gens compétents sur les trucs durs sont trop chers pour leur faire perdre du temps sur Git, soit (dans le cas d'un article) parce qu'il y a une deadline, et qu'on préfère faire des maths que faire du Git.
Il y a un coût caché non-négligeable dans ce type de projet, c'est le coût de changer de contexte. Si je suis en train de faire du code ou d'écrire du LaTeX, ça me demande souvent une concentration importante. Si j'ai à réfléchir à mes branches et mes rebases, et à réparer ce qui casse, je dois me remettre dans le problème après avoir réparé, et ça coûte du temps.
Le plus gros problème est que le patch minimal n'est pas unique. Par extension, diff3 a parfois plusieurs choix, ce qui est assez inquiétant, parce que Git peut parfois mélanger des lignes un peu n'importe comment.
Non (de très loin), et oui, à 100%, sans patchs sémantiques.