Je n'ai pas vu à quel moment il a été fait mention d'un concept mathématique relativement avancé en termes profanes.
Non bien sûr, les graphes orientés c'est du bon sens populaire, l'autre jour j'en parlais avec ma boulangère. Elle m'a d'ailleurs dit "oublie pas d'étiqueter les arêtes sinon c'est un peu trop simple".
les deux graphes colorés un peu différents
D'accord je vois certains cas où le comportement de git peut différer suivant la stratégie choisie. Ce sont des symptômes de "n'importe quoi as a process". J'ai essayé de l'illustrer avec du "vrai code" avec mon histoire de validation d'utilisateur (pas terrible mais mieux que vos exemples soit sans code tout court (intéressant pour un gestionnaire de sources) soit avec des exemples encore moins réalistes et spécialement conçus dans votre sens pour que les parties en conflit aient exactement la même apparence, pour qu'on puisse les confondre alors que rien ne permet à priori de supposer qu'elles seront identiques) et la conclusion qu'on m'a livrée c'est "ah bah là pijul arrête aussi de bosser en disant qu'il y a conflit".
Si ça te fait mal de te taper sur le tibia avec une serpette, est-ce que vraiment la bonne solution c'est de la remplacer par une serpette en mousse ?
dans tous les cas on arrivera sur le même état Q
Premièrement : dans un cas "réel" l'auteur a été obligé d'admettre que pijul n'arrivera nul part, qu'il abandonnera en déclarant un conflit. Deuxièmement : encore heureux, si pijul décidait tout seul quoi faire, il pourrait aboutir à un arbre de sources qui ne compile pas...
là où, par construction, elle est automatiquement satisfaite dans pijul
Non. Cf. point précédent. Ou alors pour mon code de gestion d'utilisateurs, donne-moi le code final automatiquement produit (indice : il est indécidable (ça devrait te plaire comme mot)).
Outre cette propriété d'associativité des patchs, il y en a une autre fort utile : celle qui cherche à capter l'essence de fonctionnalités orthogonales ou indépendantes. Si, dans un commit, je modifie une partie d'un fichier, puis dans le commit suivant j'en modifie une autre qui n'a rien à voir : peu importe l'ordre dans lequel je les réalise, on devrait aboutir au même résultat.
Je veux pas te provoquer de douleur psychique à base de dissonance cognitive, mais, breaking news, dans ce cas de figure (modifications non colocalisées) git fera la même chose !
Les guides de bonnes pratiques expliquent également comment obtenir une telle chose en git
Non, tu ne les as pas compris. Cf. argument précédent : si deux patchs ne se recouvrent pas "géographiquement" ils sont interchangeables.
Ça va faire très argument d'autorité, mais je bosse avec git depuis bientôt 10 ans, et il semble que je sois gâté par la nature sur ce point, ou que j'ai la même topologie neuronale que Linus, car même mes collègues très intelligents se tournent vers moi quand il faut "un guru git" et je suis extrêmement à l'aise avec. Ça n'est pas un argument pro-git (au contraire, à la limite...), c'est pour dire que si tu veux attaquer git avec des exemples, muscle ton jeu, car sortir des contre-vérités évidentes comme ça ne t'aide pas.
La problématique de fiabiliser la production logicielle m'intéresse réellement. C'est le fait de pouvoir y prendre une bonne part dans ma nouvelle boite, qui m'a fait accepter ce poste. Je suis un fan de git, mais si concrètement pijul apporte de vraies avancées, j'en parlerai au boulot ! Néanmoins, pour l'instant je vois :
des approximations voire des contre-vérités sur git
Certaines par toi que je viens de pointer, certaines par un des auteurs de pijul même, pointées par d'autres ailleurs dans les commentaires.
des grands discours faux dans la réalité du travail de développeur
OK c'est super que pijul ait une théorie lui permettant de toujours produire un résultat déterministe au lieu de lâcher l'affaire ou de diverger; sauf que tu oublies un petit détail : je m'en fous que pijul ait une théorie lui garantissant de toujours être un endomorphisme de "l'ensemble des combinaisons de chaines de caractère" (les "sources") et donc de ne jamais être indéterminé (aucun résultat) ou une distribution (plusieurs "ordonnées" pour une abscisse), car dans le monde réel nous ne travaillons pas sur "l'ensemble des combinaisons de chaines de caractère" mais "l'ensemble des combinaisons de chaines de caractère ayant un sens" (que ce soit un sens du point de vue du compilateur, ou pire du point de vue de leur but métier, c'est-à-dire qu'il faut qu'elles compilent mais en plus qu'elles fassent ce qu'on voulait exprimer).
Et ça pijul ne le garantit évidemment pas, puisqu'il ne parle pas tous les langages de programmation / de balisage / les langues du monde (si on décide de versionner un manuscrit par exemple), et n'a encore moins conscience des specs du code. Je pense l'avoir illustré par mon exemple de fonction de récupération d'utilisateur. Je ne changerai pas d'avis tant qu'on ne m'aura pas prouvé que pijul résout le problème.
Indice avant que tu t'échines pour rien : l'auteur de pijul a dit qu'il fera comme git, qu'il s'arrêtera sur un conflit (merde c'est pas un endomorphisme défini sur tout l'ensemble des "trucs à versionner" alors ?? :-( ), alors c'est pas avec tes petits graphiques sans contenu que tu y arriveras.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Sufflope (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 3.
Non bien sûr, les graphes orientés c'est du bon sens populaire, l'autre jour j'en parlais avec ma boulangère. Elle m'a d'ailleurs dit "oublie pas d'étiqueter les arêtes sinon c'est un peu trop simple".
D'accord je vois certains cas où le comportement de git peut différer suivant la stratégie choisie. Ce sont des symptômes de "n'importe quoi as a process". J'ai essayé de l'illustrer avec du "vrai code" avec mon histoire de validation d'utilisateur (pas terrible mais mieux que vos exemples soit sans code tout court (intéressant pour un gestionnaire de sources) soit avec des exemples encore moins réalistes et spécialement conçus dans votre sens pour que les parties en conflit aient exactement la même apparence, pour qu'on puisse les confondre alors que rien ne permet à priori de supposer qu'elles seront identiques) et la conclusion qu'on m'a livrée c'est "ah bah là pijul arrête aussi de bosser en disant qu'il y a conflit".
Si ça te fait mal de te taper sur le tibia avec une serpette, est-ce que vraiment la bonne solution c'est de la remplacer par une serpette en mousse ?
Premièrement : dans un cas "réel" l'auteur a été obligé d'admettre que pijul n'arrivera nul part, qu'il abandonnera en déclarant un conflit. Deuxièmement : encore heureux, si pijul décidait tout seul quoi faire, il pourrait aboutir à un arbre de sources qui ne compile pas...
Non. Cf. point précédent. Ou alors pour mon code de gestion d'utilisateurs, donne-moi le code final automatiquement produit (indice : il est indécidable (ça devrait te plaire comme mot)).
Je veux pas te provoquer de douleur psychique à base de dissonance cognitive, mais, breaking news, dans ce cas de figure (modifications non colocalisées) git fera la même chose !
Non, tu ne les as pas compris. Cf. argument précédent : si deux patchs ne se recouvrent pas "géographiquement" ils sont interchangeables.
Ça va faire très argument d'autorité, mais je bosse avec git depuis bientôt 10 ans, et il semble que je sois gâté par la nature sur ce point, ou que j'ai la même topologie neuronale que Linus, car même mes collègues très intelligents se tournent vers moi quand il faut "un guru git" et je suis extrêmement à l'aise avec. Ça n'est pas un argument pro-git (au contraire, à la limite...), c'est pour dire que si tu veux attaquer git avec des exemples, muscle ton jeu, car sortir des contre-vérités évidentes comme ça ne t'aide pas.
La problématique de fiabiliser la production logicielle m'intéresse réellement. C'est le fait de pouvoir y prendre une bonne part dans ma nouvelle boite, qui m'a fait accepter ce poste. Je suis un fan de git, mais si concrètement pijul apporte de vraies avancées, j'en parlerai au boulot ! Néanmoins, pour l'instant je vois :
Certaines par toi que je viens de pointer, certaines par un des auteurs de pijul même, pointées par d'autres ailleurs dans les commentaires.
OK c'est super que pijul ait une théorie lui permettant de toujours produire un résultat déterministe au lieu de lâcher l'affaire ou de diverger; sauf que tu oublies un petit détail : je m'en fous que pijul ait une théorie lui garantissant de toujours être un endomorphisme de "l'ensemble des combinaisons de chaines de caractère" (les "sources") et donc de ne jamais être indéterminé (aucun résultat) ou une distribution (plusieurs "ordonnées" pour une abscisse), car dans le monde réel nous ne travaillons pas sur "l'ensemble des combinaisons de chaines de caractère" mais "l'ensemble des combinaisons de chaines de caractère ayant un sens" (que ce soit un sens du point de vue du compilateur, ou pire du point de vue de leur but métier, c'est-à-dire qu'il faut qu'elles compilent mais en plus qu'elles fassent ce qu'on voulait exprimer).
Et ça pijul ne le garantit évidemment pas, puisqu'il ne parle pas tous les langages de programmation / de balisage / les langues du monde (si on décide de versionner un manuscrit par exemple), et n'a encore moins conscience des specs du code. Je pense l'avoir illustré par mon exemple de fonction de récupération d'utilisateur. Je ne changerai pas d'avis tant qu'on ne m'aura pas prouvé que pijul résout le problème.
Indice avant que tu t'échines pour rien : l'auteur de pijul a dit qu'il fera comme git, qu'il s'arrêtera sur un conflit (merde c'est pas un endomorphisme défini sur tout l'ensemble des "trucs à versionner" alors ?? :-( ), alors c'est pas avec tes petits graphiques sans contenu que tu y arriveras.