On tourne en rond. Je te dis que git est génial pour des choses qui n'ont rien à voir avec la théorie des patchs, et tu me rétorques qu'il lui manque la théorie des patchs...
Je comprends que ça pouvait être mal interprété. C'était uniquement un exemple d'un principe sur lequel Git pourrait être basé. On n'a pas besoin de théorie des patchs pour avoir l'associativité. Peut-être qu'il existe une alternative à 3-way merge qui est associative.
Ceci dit, cette question est étrange : les gens qui croient que Git donne certaines garanties à l'utilisateur devraient être en mesure d'énoncer ces garanties (garanties = axiomes = principes), plutôt que l'inverse.
Mais j'avoue que je n'aime pas trop tes arguments se rapportant à « on a discuté avec des gens qui savent, et vous ne pouvez pas comprendre leurs problèmes », en gros, si je caricature.
C'est une caricature d'autant plus grossière que j'avais énoncé quelques unes des raisons factuelles pour lesquelles un très gros utilisateur pourrait ne pas vouloir de Git, et que des liens vers des blogs de Facebook et Google ont été postés dans la même discussion (pas par moi).
Moi par exemple je kiffe le design orienté format de données plutôt qu'API
Là-dessus, on est totalement d'accord. À tel point que Pijul est exactement ça : une nouvelle structure de données, dont la principale nouveauté est d'être tolérante aux conflits.
(dire qu'on ne retrouve pas les concepts d'Unix dans git, inventé par le créateur de l'Unix libre majoritaire aujourd'hui... je comprends pas)
Je suis d'accord qu'il y a un peu de l'esprit Unix dans Git. Par exemple, le fait que beaucoup de choses soient accessibles avec des scripts shell.
Mais Torvalds n'a pas inventé C et Unix (et c'est un argument d'autorité).
Du point de vue des concepts, les concepts d'Unix et de C sont simples et élégants, il n'y a souvent qu'une seule façon de faire chaque chose (je ne parle pas des commandes shell, qui sont une petite partie du design d'Unix, mais plutôt des appels systèmes), un petit nombre de concepts avec des rapports clairs et déterministes entre eux. Si tu prends deux concepts quelconques d'Unix ou de C, ils ne seront jamais liés par une heuristique qui peut parfois se planter. Exemple : mmap n'utilise pas une heuristique pour savoir s'il doit mapper un seul fichier, ou deux l'un au-dessus de l'autre (cet exemple est tiré par les cheveux, mais comme Unix est designé très rigoureusement, on ne peut pas trouver ce type d'exemples).
Dans Git, ce n'est pas le cas pour tout. Par exemple, il y a plein de façons de faire ce qu'on veut (de l'aveu de Torvalds lui-même).
Un autre exemple, on voit régulièrement des explications de Git pour des débutants qui commencent par "un commit n'est pas un patch" (plutôt que de dire ce que c'est), on voit plus rarement des explications d'Unix qui commencent par "un fichier n'est pas ..." ou "un pointeur n'est pas ...".
C'était une blague, même si elle n'était pas drôle. Désolé.
Bon, vu les commentaires d'autres sur ce fil, je ne pouvais pas trop savoir. Désolé !
[^] # 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é à 2.
Je comprends que ça pouvait être mal interprété. C'était uniquement un exemple d'un principe sur lequel Git pourrait être basé. On n'a pas besoin de théorie des patchs pour avoir l'associativité. Peut-être qu'il existe une alternative à 3-way merge qui est associative.
Ceci dit, cette question est étrange : les gens qui croient que Git donne certaines garanties à l'utilisateur devraient être en mesure d'énoncer ces garanties (garanties = axiomes = principes), plutôt que l'inverse.
C'est une caricature d'autant plus grossière que j'avais énoncé quelques unes des raisons factuelles pour lesquelles un très gros utilisateur pourrait ne pas vouloir de Git, et que des liens vers des blogs de Facebook et Google ont été postés dans la même discussion (pas par moi).
Là-dessus, on est totalement d'accord. À tel point que Pijul est exactement ça : une nouvelle structure de données, dont la principale nouveauté est d'être tolérante aux conflits.
Je suis d'accord qu'il y a un peu de l'esprit Unix dans Git. Par exemple, le fait que beaucoup de choses soient accessibles avec des scripts shell.
Mais Torvalds n'a pas inventé C et Unix (et c'est un argument d'autorité).
Du point de vue des concepts, les concepts d'Unix et de C sont simples et élégants, il n'y a souvent qu'une seule façon de faire chaque chose (je ne parle pas des commandes shell, qui sont une petite partie du design d'Unix, mais plutôt des appels systèmes), un petit nombre de concepts avec des rapports clairs et déterministes entre eux. Si tu prends deux concepts quelconques d'Unix ou de C, ils ne seront jamais liés par une heuristique qui peut parfois se planter. Exemple : mmap n'utilise pas une heuristique pour savoir s'il doit mapper un seul fichier, ou deux l'un au-dessus de l'autre (cet exemple est tiré par les cheveux, mais comme Unix est designé très rigoureusement, on ne peut pas trouver ce type d'exemples).
Dans Git, ce n'est pas le cas pour tout. Par exemple, il y a plein de façons de faire ce qu'on veut (de l'aveu de Torvalds lui-même).
Un autre exemple, on voit régulièrement des explications de Git pour des débutants qui commencent par "un commit n'est pas un patch" (plutôt que de dire ce que c'est), on voit plus rarement des explications d'Unix qui commencent par "un fichier n'est pas ..." ou "un pointeur n'est pas ...".
Bon, vu les commentaires d'autres sur ce fil, je ne pouvais pas trop savoir. Désolé !