Comment les avantages que j'ai cités seraient là pour compenser un manque de principe solide ?
Je te cite :
Genre le système sous-jacent exposé et exploitable, les formats de données simples et centraux, l'état du VCS exposé dans le filesystem, l'utilisation en shell facile (pas mal de fonctions de merge de git sont même juste du shell !).
En gros: trop bien, on peut aller le bricoler. Sauf qu'on n'a essentiellement besoin de le bricoler parce qu'on se retrouve dans une situation pourrie à cause du manque de théorie solide dessous.
Quels principes exactement, puisqu'ils ne sont pas en rapport avec la théorie des patchs, à priori ?
Des principes, ce serait une liste d'axiomes que Git garantit à l'utilisateur. L'associativité serait un exemple.
Pour quelqu'un qui me sort qu'il connaît git mieux que tout le monde ici
Je n'ai absolument jamais dit ça. J'ai peut-être suggéré d'écouter mes arguments avant de dire "Git sera de toute façon tellement mieux que je n'ai pas besoin de t'écouter".
WTF2 ?! Git ne stock aucun diff lié à un commit
C'est vrai, j'ai écrit ça un peu tard et en décalage horaire, excuse-moi, ça fait bien longtemps que je n'ai pas regardé les entrailles de Git.
Ceci dit, ça n'enlève rien à mon argument, au contraire : le fait qu'il t'affiche un diff et qu'il travaille sur un objet complètement différent n'est pas ce que ferait C ou Unix, qui n'ont pas ce type de décalage.
Après, je vois qu'on a une idée du design logicielle assez différente
Plus de détails !
je trouve les concepts d'Unix, qu'on retrouve dans Git, vraiment géniaux.
Ce n'est pas exactement ce que j'ai dit dans mon commentaire précédent ? À part le fait qu'on ne retrouve à mon avis pas les concepts d'Unix dans Git, pour les raisons que j'ai déjà données, et que tu n'as pas vraiment commentées directement (à part à coups de WTF sur mes imprécisions techniques, et de "Git est mieux de toute façon").
je vais ajouter un argument d'autorité : tu as l'air plus jeune que moi
C'est une raison légitime pour ne pas écouter ce que je dis, et c'est honnête de le reconnaître.
[^] # 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é à 4.
Je te cite :
En gros: trop bien, on peut aller le bricoler. Sauf qu'on n'a essentiellement besoin de le bricoler parce qu'on se retrouve dans une situation pourrie à cause du manque de théorie solide dessous.
Des principes, ce serait une liste d'axiomes que Git garantit à l'utilisateur. L'associativité serait un exemple.
Je n'ai absolument jamais dit ça. J'ai peut-être suggéré d'écouter mes arguments avant de dire "Git sera de toute façon tellement mieux que je n'ai pas besoin de t'écouter".
C'est vrai, j'ai écrit ça un peu tard et en décalage horaire, excuse-moi, ça fait bien longtemps que je n'ai pas regardé les entrailles de Git.
Ceci dit, ça n'enlève rien à mon argument, au contraire : le fait qu'il t'affiche un diff et qu'il travaille sur un objet complètement différent n'est pas ce que ferait C ou Unix, qui n'ont pas ce type de décalage.
Plus de détails !
Ce n'est pas exactement ce que j'ai dit dans mon commentaire précédent ? À part le fait qu'on ne retrouve à mon avis pas les concepts d'Unix dans Git, pour les raisons que j'ai déjà données, et que tu n'as pas vraiment commentées directement (à part à coups de WTF sur mes imprécisions techniques, et de "Git est mieux de toute façon").
C'est une raison légitime pour ne pas écouter ce que je dis, et c'est honnête de le reconnaître.