Oui, sauf que ce problème peut être utilisé pour créer des failles dans un logiciel
Mouarf, avec ton exemple, là ? Je veux bien un exemple concret, pour moi ça reste un cas irréaliste.
Sur les autres avantages et "Git va être le meilleur", c'est un peu ce qu'on disait de SVN quand Git est sorti.
Ah bon ? J'ai pas souvenir de ça. Dès le début, c'était le soft « codé par Torvalds » et même s'il était difficile d'accès, très vite les gens ont reconnu sa supériorité (et les problèmes de SVN) même si on imaginait une période de transition pendant laquelle SVN allait rester encore présent. Mais j'ai rarement vu un soft prendre de l'ampleur aussi rapidement que git !
Il n'est pas 100% honnête (et même pas 99,999% honnête) de dire "Git est supérieur" en oubliant les questions essentielles du temps d'apprentissage et du passage à l'échelle sur de gros dépôts et de grosses équipes.
Oui c'est vrai. Mais étant partisan des courbes d'apprentissage paraboliques, j'estime que ça vaut le coup à long terme.
Par contre, on ne l'a absolument jamais entendu des gens avec qui on a parlé qui travaillent sur de très gros trucs (par exemple chez Apple ou Facebook, ou même des gens qui gèrent les dépôts du noyau Linux).
Chez Facebook & co, et dans les entreprises en général, il y a des contraintes particulières qui font qu'il est moins adapté, mais ce sont pour moi de mauvaises raisons : soit ça donne trop de liberté aux devs et les chefs n'aiment pas ça (git c'est vraiment pour que chaque dev soit complètement indépendant, c'est très présent dans son idéologie, ya pas à dire), soit ça n'intègre pas tout le nécessaire d'intégration et on le tord pour en faire un outil d'intégration et ça marche mal, soit on fait des trucs crades parce que « on n'a pas le temps » et du coup ça foire parce que les branches deviennent n'importe quoi. Bref, oui, git impose une certaine méthodologie de développement (bien qu'il n'impose pas de workflow particulier), et c'est celle qui est au cœur du Libre : indépendance, fonctionnalités bien isolées (il y a d'autres outils pour l'intégration), et nécessité d'être plutôt propre et maintenable car c'est le seul moyen d'être gérable quand peu de gens contribuent.
C'est intéressant de se poser ces questions (même si pour « des gens qui gèrent les dépôts du noyau Linux », je suis sceptique), mais je pense que ça a très peu à voir avec la théorie des patchs. Après, si tu veux t'atteler à la résolution des autres « défauts » de git, pourquoi pas, mais à ce moment-là ça n'est plus une histoire de théorie des patchs, qui semble pourtant être ton cheval de bataille ici.
Et on soupçonne un tout petit peu que les gens qui nous disent ça "oublient" en général de mentionner qu'ils ont passé 10 ans à essayer de le comprendre, lus des quantités ahurissantes de livres, de blogs et de manuels pour essayer de forcer Git à rester dans les clous des axiomes que Pijul garantit au débutant qui fait son premier dépôt avec un pote, sans avoir la moindre idée de ces trucs ni de notre théorie.
Je pense rentrer dans ta description, effectivement, même si elle est légèrement exagérée sur les besoins de maîtriser git comme il faut ; on y arrive avant 10 ans en général :-) Cependant, je suis convaincu que ça en vaut la peine. Alors que souvent, les soft plus abordables, c'est agréable à utiliser au début, puis quand on les maîtrise bien, ils deviennent limitants et on passe à autre chose...
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par benoar . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 3.
Mouarf, avec ton exemple, là ? Je veux bien un exemple concret, pour moi ça reste un cas irréaliste.
Ah bon ? J'ai pas souvenir de ça. Dès le début, c'était le soft « codé par Torvalds » et même s'il était difficile d'accès, très vite les gens ont reconnu sa supériorité (et les problèmes de SVN) même si on imaginait une période de transition pendant laquelle SVN allait rester encore présent. Mais j'ai rarement vu un soft prendre de l'ampleur aussi rapidement que git !
Oui c'est vrai. Mais étant partisan des courbes d'apprentissage paraboliques, j'estime que ça vaut le coup à long terme.
Chez Facebook & co, et dans les entreprises en général, il y a des contraintes particulières qui font qu'il est moins adapté, mais ce sont pour moi de mauvaises raisons : soit ça donne trop de liberté aux devs et les chefs n'aiment pas ça (git c'est vraiment pour que chaque dev soit complètement indépendant, c'est très présent dans son idéologie, ya pas à dire), soit ça n'intègre pas tout le nécessaire d'intégration et on le tord pour en faire un outil d'intégration et ça marche mal, soit on fait des trucs crades parce que « on n'a pas le temps » et du coup ça foire parce que les branches deviennent n'importe quoi. Bref, oui, git impose une certaine méthodologie de développement (bien qu'il n'impose pas de workflow particulier), et c'est celle qui est au cœur du Libre : indépendance, fonctionnalités bien isolées (il y a d'autres outils pour l'intégration), et nécessité d'être plutôt propre et maintenable car c'est le seul moyen d'être gérable quand peu de gens contribuent.
C'est intéressant de se poser ces questions (même si pour « des gens qui gèrent les dépôts du noyau Linux », je suis sceptique), mais je pense que ça a très peu à voir avec la théorie des patchs. Après, si tu veux t'atteler à la résolution des autres « défauts » de git, pourquoi pas, mais à ce moment-là ça n'est plus une histoire de théorie des patchs, qui semble pourtant être ton cheval de bataille ici.
Je pense rentrer dans ta description, effectivement, même si elle est légèrement exagérée sur les besoins de maîtriser git comme il faut ; on y arrive avant 10 ans en général :-) Cependant, je suis convaincu que ça en vaut la peine. Alors que souvent, les soft plus abordables, c'est agréable à utiliser au début, puis quand on les maîtrise bien, ils deviennent limitants et on passe à autre chose...