Ça n'est pas pour te décourager, tu dis toi-même que c'est un projet d'expérimentation, et c'est très bien. Dire que la théorie des patchs, « c'est bien », oui, peut-être, mais je ne vois pas en quoi en pratique ça changera quoi que ce soit : l'exemple donné dans ton premier commentaire est complètement tiré par les cheveux et n'arrivera jamais en pratique.
Oui, sauf que ce problème peut être utilisé pour créer des failles dans un logiciel, même open source, et même en passant les reviews et les tests : aucun test unitaire ne peut garantir l'intégralité d'un code, et d'ailleurs toutes les failles de sécurité qui arrivent (on en découvre tous les jours presque partout) avaient échappé aux tests unitaires dans 100% des cas (encore mieux que 99,999%).
Sur les autres avantages et "Git va être le meilleur", c'est un peu ce qu'on disait de SVN quand Git est sorti.
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.
Dans la vraie vie, on a parlé avec pas mal de monde depuis qu'on a commencé ce projet, et on a déjà entendu (assez rarement quand même) ce "je comprends tout Git, et c'est tellement mieux que votre truc que je ne vais même pas aller regarder ce que c'est".
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).
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.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 10.
Oui, sauf que ce problème peut être utilisé pour créer des failles dans un logiciel, même open source, et même en passant les reviews et les tests : aucun test unitaire ne peut garantir l'intégralité d'un code, et d'ailleurs toutes les failles de sécurité qui arrivent (on en découvre tous les jours presque partout) avaient échappé aux tests unitaires dans 100% des cas (encore mieux que 99,999%).
Sur les autres avantages et "Git va être le meilleur", c'est un peu ce qu'on disait de SVN quand Git est sorti.
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.
Dans la vraie vie, on a parlé avec pas mal de monde depuis qu'on a commencé ce projet, et on a déjà entendu (assez rarement quand même) ce "je comprends tout Git, et c'est tellement mieux que votre truc que je ne vais même pas aller regarder ce que c'est".
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).
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.