rewind a écrit 3425 commentaires

Ça me rassure de voir que le comportement que je décris peut arriver dans certains cas (heureusement, pas tous). J'espère que ça réussira à convaincre ceux qui m'affirment que non, non, non c'est toujours mieux avec git que, ben pas forcément.

>> ce qui te gène c'est la possibilité de pouvoir faire un pull d'un dépot différent de celui où on fait un push car ça faciliterais le maintient d'une version alternative du logiciel ?

En quelque sorte, oui.

>> D'une manière générale, je pense qu'il est mauvais de croire qu'un problème « social » peut être résolu par la technique. Ça me semble illusoire et ça peut toujours être contrecarré.

Et pourtant, avec notre OS préféré (que ce soit BSD ou Linux d'ailleurs), nous sommes entourés de mesures techniques qui règlent des problèmes sociaux. Ne serait-ce que l'existence de droits, et du compte root, "pour pas que les utilisateurs normaux fassent n'importe quoi", alors que c'est juste pour empêcher qu'ils puissent faire n'importe quoi, qu'ils en aient la possibilité. Et oui, ça peut être contourné et même des gens s'y emploient à longueur de journée. N'empêche que ça marche bien la plupart du temps.

Alors, je vais commencer par te dire comme à Matthieu Moy : on se calme, pas la peine d'être aussi agressif. Je sais que vous êtes deux aficionados de git, mais là, je vous trouve tous les deux assez agressifs. Surtout que je dis que je vais essayer de m'y mettre à git, donc pas la peine de me parler de "fermer des fonctionnalités" blabla.

Bref, pour répondre à ta première question, je vais t'en poser une autre : tu as des exemples concrets de programme en C avec des memory leaks ?

Tout d'abord, on se calme hein, pas la peine d'être aussi agressif.

Ensuite, dans la phrase que tu cites, il y a exactement ce que je décris dans mon texte initial : avec un VCS, le gars qui fait des modifs est obligé de discuter avec upstream, il est obligé de s'intégrer socialement avec le projet, il est obligé de collaborer s'il veut que ses modifs soient intégrées, parce qu'il est relativement difficile de maintenir un patch en dehors de la "branche principale" (parce que justement, ce n'est pas fait pour ça). Alors qu'un DVCS, tu peux avoir ton fork sur ton site, sans en parler à upstream. Ce que ça change (puisque c'est ta question), c'est que dans un cas, tu as une obligation technique de collaborer, dans l'autre cas, tu as une permission technique de ne pas collaborer. Et ma thèse, c'est que ça peut engendrer des comportements idoines, en ce sens qu'avec un DVCS, tu peux faire ton égoiste dans ton coin, chose impossible avec un VCS. Et j'insiste bien sur "peux", parce qu'effectivement, on peut faire autrement aussi et ça se passe bien dans la plupart des cas (heureusement).

Quant à Linux, ce n'est pas un workflow où chacun garde tout dans son coin sur son site, c'est un workflow assez complexe et très hiérarchique où tout est public, au vu et au su de tous. Donc ça ne rentre vraiment pas dans le comportement que je critique. Et d'ailleurs, ceux qui s'y essaient dans le développement de Linux se font taper sur les doigts (comme Google récemment). Ce qui n'est pas imposé par le VCS l'est par la communauté. Il n'y a qu'à voir la procédure d'acception des patchs où un des premiers trucs qui est dit est : en parler sur la LKML, c'est à dire s'intégrer socialement avec le projet, et la boucle est bouclée.

En fait, ce que tu dis, c'est que si on choisit un workflow comparable à Subversion, on n'a aucun problème, ce dont je suis absolument persuadé. Si je continue à utiliser ma comparaison avec le C, c'est comme si tu me disais qu'avec C, on peut bien coder, et je suis tout à fait d'accord. Il n'empêche qu'on peut mal coder en C et on peut utiliser git autrement que dans ce cas.

D'accord, du coup, je ne suis pas trop d'accord avec l'argument de l'auteur qui consiste à dire que c'est mieux. Au final, oui on voit que ça a été développé dans une branche mais bon, est-ce qu'il y a un intérêt supérieur à ça ?

Je reprends alors. D'un côté, tu as SVN qui peut faire des branches et des merges, et qui peut faire des changelists. Mais ces deux fonctionnalités sont considérés comme avancés (dans le svn book, elles sont dans un chapitre très éloigné du début) et personne ne les utilise, soit par peur ("c'est avancé, donc ça doit être dur"), soit par méconnaissance ("je ne lis pas les chapitres sur les utilisations avancés, j'en aurai pas besoin"). De l'autre côté, tu as git, qui peut faire des branches et des merges, et qui a une staging area qui permet plein de choses (dont l'équivalent des changelists). Là, ces deux fonctionnalités sont considérés comme basiques et apparaissent dans tous les turoriels, souvent au tout début pour la staging area. Donc les gens l'utilisent parce qu'ils connaissent ces fonctionnalités et qu'ils considèrent qu'elles font partie des fonctionnalités de base (donc faciles).

Je vais te faire la réponse que j'ai lue quelque part à propos d'un autre sujet : c'est dans la partie advanced topics (autant dire que personne ne le lit, et moi le premier, je n'avais jamais entendu parler de ça, ça n'apparaît dans aucun tutos SVN). Je l'ai lu sur les branches, qui sont considérées comme un fonctionnement normal dans git et comme un truc avancé dans SVN. Ici, la staging area, c'est sur la deuxième page de Git Reference (la première page, c'est git init et git clone, autant dire pas grand chose).

Ça veut dire que les diagrammes sont faux dans le billet du blog ?

C'est bien, tu décris exactement le comportement que je désapprouve dans mon argumentaire : le gars qui forke dans son coin sans rien dire au mainteneur. Les projets qui ouvrent leur dépôt ne sont pas si rares. Si on regarde KDE, qui n'est pas un petit projet, il me semble que les conditions pour avoir un accès au SVN ne sont pas si terrible [1], ça implique seulement de se conformer à une politique de commit, mais le compte SVN en lui-même n'est pas difficile à avoir.

[1] http://developer.kde.org/documentation/other/developer-faq.h(...)

Effectivement, ce modèle est assez complexe. Et personnellement, j'aurais inversé master et develop, c'est-à-dire que je ferais le développement dans master et que j'aurais une branche release. Et là me vient une question, est-ce que dans ce modèle, un tag ne suffirait-il pas ? Quelle est la nécessité d'avoir cette branche spécialement pour la release ? En fait, je me dis qu'un tag suffirait, et s'il y a besoin d'un hotfix, on crée une branche à ce moment là à partir du tag. Ça marche ça ?

Sinon, ça donne des idées d'organisation. Merci beaucoup.

La seule chose que je n'ai pas compris, c'est qu'il utilise --no-ff. Je vois vraiment pas l'intérêt. Est-ce qu'il ne perd pas toutes les micros étapes qu'il a fait dans la branche ? Du coup, quel intérêt de bien découper en micro étape (en plus, il insiste pour bien séparer) si tous les commits sont regroupés en un seul dans sa branche develop et qu'il supprime sa branche feature ? Bref, soit il y a qqch que je n'ai pas bien compris, soit il explique mal, soit il fait un truc idiot.

Merci pour toutes ces indications et pour le lien.

>> (Bon j'ai encore pondu un roman. Désolé pour le paté, j'espère que je n'ai pas noyé les potentielles informations importantes dans le bruit).

Ça m'aurait ennuyé que tu répondes en 140 caractères...

Je connaissais son existence mais là, l'idée, c'est de passer en 100% git, sinon ça va gâcher le plaisir...

Sauf quand la liste des fichiers est super longue... Un exemple tout bête : le refactoring. Tu bosse sur un truc et là, tu t'aperçois qu'il faut refactorer et que ça touche plein de fichiers. Mais tu aimerais envoyer le commit du refactoring tout seul, mais tu as déjà modifié d'autres fichiers. Là, pas de solution, généralement, ça finit en commit qui inclus deux trucs qui n'ont rien à voir.

Je comprends bien tout ce que tu dis, et c'est généralement l'avis des fans de git que je trouve généralement en face de moi quand j'expose ma thèse. Donc, je ne vais pas continuer le troll. Juste apporter quelques précisions :
- l'argument "c'est plus répandu donc c'est mieux", je le bannis directement, c'est un argument d'autorité, je suis un scientifique, on me convainct mieux avec des arguments scientifiques. Donc, là, je suis d'accord avec toi (et pas d'accord avec ton lead dev).
- je ne dis pas qu'un outil distribué va à l'encontre du partage, je ne dis pas que c'est malsain, je dis que ça peut induire des comportements malsain. Tout comme le C peut induire des comportements de codage dangereux, ça ne veut pas dire que le C est dangereux ou que le C va à l'encontre de la sécurité. Tu vois ce que je veux dire ? Et c'est cette possibilité qui me chagrine et que je trouve assez absente des VCS. Mais après, je peux me tromper et avoir une mauvaise vision.
- le workflow de Linux est certes exemplaire, mais ce n'est qu'un exemple de workflow parmi tout ceux proposés par git.


Puisque je te tiens, je vais te poser une question purement pratique : quand créer une branche ? Parce que selon les tutos, il y a la méthode "je crée une branche par grosse fonctionnalité", ou alors "je crée une branche quand j'ai un développement qui va vraiment diverger". Quels sont les bonnes pratiques en la matière ?

Dans le cas d'un développement ouvert (cas des projets libres), on ne peut pas "juste pousser bêtement", enfin pas trop souvent. Du coup, on est obligé de discuter avant sur une liste par exemple ou sur IRC. Ça permet de savoir qui fait quoi, qui bosse sur quoi, qui va faire de grosses modifs, etc. Bref, du contact humain. Je trouve qu'on peut perdre cet aspect avec un DVCS, cet aspect social, hautement important dans le libre.

>> Sous \LaTeX, on trouve beaucoup d'extrémistes de la typographie préconisant de ne jamais faire des lignes de plus de 70 caractères en largeur.

C'est pas une position extrêmiste, c'est une position pragmatique. C'est le résultat d'études qui montre qu'avec des lignes plus longues, les yeux fatiguent plus vite parce qu'ils doivent chercher plus longtemps le début de la ligne suivante. Si on pousse à l'extrême, en mettant des lignes très longues, on sait bien que si on n'a pas une règle, c'est très pénible de retrouver la ligne et ça coupe la lecture. 70 caractères, c'est juste la limite haute du pas-pénible.

Si on pousse ce raisonnement jusqu'au bout, on peut aller très vite dans l'absurde. Parce qu'on ne va pas rembourser les gens qui court, et donc s'expose à des risques cardio-vasculaires plus que la moyenne, et on ne va plus rembourser les skieurs qui se mettent délibérément en danger d'avoir des fractures des membres, et on ne va plus rembourser les piétons qui se mettent en danger en traversant les routes, etc.

La solidarité, c'est pas à choix. La solidarité à choix, ça s'appelle l'aumône. La solidarité, c'est faire partie d'un même groupe (ici, tous ceux qui sont sur le territoire français) et ne pas discriminer dans l'aide qu'on peut leur apporter. Parce que si on commence, on n'a pas fini de tomber sur des cas particuliers...

Houla ! L'État n'est pas une entreprise hein, son but n'est pas de fournir un service mais d'oeuvrer pour l'intérêt général. Et parfois ça passe par une mise en dehors du "marché" de certains domaines. Après, c'est à chaque État de déterminer ce qui doit relever du service public et ce qui doit relever du privé (enfin, avec l'UE, c'est moins vrai).

Personnellement, je pense qu'il faudrait en faire un service public et le placer en dehors du marché, parce que là, on se fait enfler gravement.

D'un autre côté, il ne fait que reprendre une note de son blog...

Elle reçoit de l'argent des cotisations sociales (ce que le MEDEF nomme "les charges"). Sans cotisation sociale, pas de sécurité sociale. D'ailleurs, ce n'est pas l'État qui gère mais les organismes de sécurité sociale qui sont pilotés en partie par les syndicats (non, leur rôle ne se limite pas à "prendre en otage les clients").

Je crois que tu n'as pas idée du prix d'un traitement contre le cancer. En France, la santé ne coûte pas cher, contrairement aux idées reçues, parce qu'on a encore un semblant de système solidaire. Mais ça coûte quand même énormément. Un vieux en fin de vie, on lui file dans le meilleur des cas quelques traitements palliatifs.

Les technocrates ont surtout voulu protéger la santé de ceux qui travaillent dans les restaurants. La tienne, ils s'en foutent, tu en fais ce que tu veux.

En partie faux, les cotisations sociales sont dirigés directement vers le secteur concerné : santé, famille, retraite, etc. C'est la grande différence entre le budget de l'État et celui de la Sécurité Sociale, les impôts prélevés par l'État vont à tout et n'importe quoi, alors que les cotisations sont préallouées et ne peuvent pas servir à autre chose. Ça a été fait exprès au début (1945) pour que les gouvernements ne puissent pas piocher dedans pour faire la guerre.

Un cancéreux, même s'il meurt plus jeune que la moyenne, coûte bien plus cher qu'un retraité en bonne santé...