• [^] # Re: Exemples concrets?

    Posté par (site web personnel, Mastodon) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 10.

    Ce n'est pas tout-à-fait exact. J'ai dû faire un peu de défense face à des commentaires de mauvaise foi.
    [...]
    Comme je l'ai déjà dit dans une autre réponse, si tu te sens efficace quand tu utilises Git, c'est très bien ! Peut-être que Pijul n'est pas pour toi.

    Hmmm... tout de même avec toutes les précautions que j'ai prises, cette réponse arrive quand même à être pas mal sur la défensive! Je pense avoir suffisamment expliqué que j'étais ouvert aux nouveautés. Et dire que j'aime bien/suis efficace avec git ne signifiait absolument pas que je ne veux pas de Pijul ou que ce n'est pas pour moi. Si c'est le cas, aurais-je vraiment écrit un super long message super diplomatique qui m'a pris du temps?
    Peut-être serais-je encore plus efficace avec Pijul, qui sait! Ce n'est donc pas antithètique (être efficace avec git vs. Pijul est pour moi? Aucun rapport, fils unique!). 😛

    Et la page du manuel "Why Pijul" a bien un lien vers un exemple concret avec du code C, où Git s'emmêle les pinceaux (en termes mathématiques, où Git n'est pas associatif) : https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html

    Ok j'avais loupé ça, c'est intéressant, merci. L'exemple aurait mérité d'être recopié avec un joli formatage dans la dépêche, en bien placé. D'un seul coup on comprend beaucoup mieux et tu te serais évité pas mal de discussions, je pense!

    C'est pour moi 100 fois plus explicatif que tous les mots mathématiques ou que les détails sémantiques (genre définir prouvé "scientifiquement" vs "mathématiquement"; désolé mais bon... 😛).

    Sur la commutativité, tu as des exemples tout le temps quand tu utilises Git :

    Encore une fois, un exemple concret ne serait pas de refus (tes 3 points ne sont pas des exemples concrets pour expliquer un tel usage). En un exemple, le coup de l'associativité est devenue concrête en 2 minutes de lecture (évitant ainsi de longs débats sur linuxfr). Ça vaudrait le coup de faire pareil avec la commutativité, non? :-)

    Chaque fois que tu fais un rebase d'une branche sur une autre. C'est une opération qui n'est jamais nécessaire dans Pijul, elle est automatique dans 100% des cas.

    Tiens là par exemple j'ai vraiment du mal à comprendre ce que tu me dis. Comment la branche peut-elle être rebasée sans demande explicite? Comment sait-elle sur quelle autre branche elle doit l'être? Et si je veux pas rebaser? Enfin bon là comme ça, ça me paraît juste magique. Ensuite y a sûrement une logique que je ne pige pas. D'où: un exemple concret serait utile.

    Rebase a d'autres usages, comme par exemple retirer un vieux commit. Pijul fait ça (la commande est unrecord) sans changer l'identité des nouveaux commits, donc si tu as déjà poussé ce n'est pas grave.

    Mais tu le retires-retires? Il n'est plus disponible du tout, plus de trace dans l'historique (genre pas comme un git revert où tu annules l'action du commit sans retirer dans l'historique)?
    C'est tout de même assez tendancieux de permettre la réécriture à volonté (pour les branches publiques, notamment communément celle appelée "master" dans git). Et ce n'est pas seulement car on casse l'historique dans git (les hashs de commit qui ne sont pas cassés dans Pijul, j'ai bien compris cette partie!), mais bien aussi car réécrire l'histoire, c'est perdre des informations. Aussi les gens avec un vieux hash de commit ne peuvent plus le retrouver. Les seuls cas considérés comme acceptables sont normalement lorsqu'on a "commité" des infos méga-confidentielles par erreur (et encore... en général si on a fait ça, il faut surtout considérer que c'est trop tard cas on ne sait pas qui en a pris connaissance; donc réécrire l'histoire ne sert en général à rien, même dans ce cas, à part limiter les dégâts éventuellement le temps de changer les infos fuitées à la source).

    C'est un autre problème que Pijul n'a pas, il y a une vraie représentation interne des conflits.

    C'est un truc que tu as répété plusieurs fois dans tes commentaires. Et c'est aussi écrit dans la page "Why Pijul". Mais ça veut dire quoi concrêtement une "vraie représentation interne des conflits", pour nous autres simples développeurs qui veulent juste versionner nos sources?

    ⚠ Je ne te demande pas de me le réexpliquer avec d'autres mots, et surtout pas des termes mathématiques! ⚠
    Encore une fois, un exemple concret vaut tous les discours. Genre un copier-coller du résultat d'un conflit de merge, et comment il est corrigé par le développeur qui utilise Pijul (genre le workflow avec les diverses commandes Pijul; qu'est-ce que le dév voit dans ses fichiers? comment les modifie-t-il? etc.). Ça, je pense que je comprendrais. :-)
    (et cette fois j'ai bien regardé si j'ai pas loupé un lien sur la page "Why Pijul? qui donne un tel exemple; et il me semble que non, ou alors c'est bien caché!)

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]