Tout ce que tu décris en terme de réorganisation est possible avec le rebase de Git.
Certes. On peut aussi écrire tout ce qu'on veut en Brainfuck, c'est Turing-complet.
La question est, à quel coût ? Si on peut faire la même chose bien plus simplement, de manière plus déterministe, plus rigoureuse et plus concise, je ne comprends vraiment pas l'argument pour s'en priver.
(J'imagine que tu réarranges le graphe des patches en modifiant les arcs).
Il n'y a pas de DAG de commits dans Pijul, juste des ensembles de patchs.
C'est pourtant écrit dans la doc existante des dizaines de fois, je l'ai redit dans mon commentaire plus haut, c'est partout dans toute notre communication, et dans les tutoriels contribués par d'autres. Je doute que des tutoriels supplémentaires changent quoi que ce soit.
En tant qu'utilisateur, le format du repo m'importe peu
Oui, moi aussi je m'en fous, mais on nous l'a demandé. Apparemment tout le monde n'a pas les mêmes intérêts.
Par contre, voir à quoi ressemble la sortie d'une commande comme "add" "status" ou "log" m'apporterait.
Je ne suis pas sûr de comprendre. Pourquoi tu ne peux pas simplement faire pijul add, pijul status ou pijul log pour voir ça ?
Si tu juges utile d'avoir ça dans la doc, tu es le bienvenue pour faire un patch du manuel:
Quid de la séparation entre la synchro (fetch) et la mise à jour du workspace (merge)? Parfois c'est utile de ne pas recourir à un "git pull" et procéder en 2 temps.
C'est utile dans Git (je le fais souvent) parce que Git peut parfois déconner complètement quand il merge, et on veut pouvoir examiner le patch avant parce qu'on sait qu'on aura du mal à revenir en arrière. Dans Pijul, ce n'est pas implémenté, mais je doute franchement de l'utilité, parce que (1) Pijul a un algo de merge correct et (2) on peut toujours revenir en arrière, dans 100% des cas.
Comment tagguer une version ? Je lis dans la FAQ que ce n'est pas implémenté. Et surtout que les perfs risquent de s'en ressentir (O(n) vs O(1) pour git). De douloureux souvenirs s'éveillent en moi, ancien utilisateur de Clearcase et de SVN.
pijul tag existe pourtant, c'est dans la doc.
Dans la FAQ, il y a un paragraphe sur la navigation dans les versions. C'est plus subtile dans Pijul que dans Git, parce que Git est séquentiel, mais ce n'est pas non plus la mort dans Pijul. C'est même un peu plus flexible, puisqu'on peut composer une version avec seulement certains patchs.
Pour l'instant, on s'en sort à coups d'unrecord (la commande qui enlève des patchs). Pour le futur, on réfléchit à une interface plus efficace, qui tirerait partie de la puissance des ensembles de patchs, tout en restant au moins aussi simple que git checkout.
Qu'en est-il du .gitignore ? Je me vois mal être obligé de préciser moi-même explicitement tous les fichiers à versionner. Est-ce que l'option --recursive du add en tient compte ?
Ce n'est pas moi qui essaie de mettre en avant les atouts de mon projet. Un peu de pédagogie serait bienvenue. Les dépêches défilent et il n'est toujours question que de "théorie".
Je veux bien répondre à des questions sur des exemples "concrets", encore faut-il me donner ces exemples. Pourquoi les branches et commits dessinés en ascii art constituent des exemples concrets, et ma réponse non ?
Même si je comprends que tu préfères t'investir sur le projet, le temps d'écrire un tutoriel aurait largement été compensé par celui que tu passes à répondre ici ou sur reddit.
Il y a déjà de la doc, à laquelle on peut contribuer, poser des questions, etc. C'est un projet open source.
Si l'objectif est de comprendre, lire la doc existante et poser des questions peut aider. Si l'objectif est de se convaincre et de convaincre les autres que Git est mieux, lire la doc de Pijul ne sert pas forcément.
Je ne doute d'ailleurs pas du tout que Git soit mieux dans plein de cas, et pour plein de gens.
[^] # Re: Soit j'ai rien compris soit...
Posté par pmeunier . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 5.
Certes. On peut aussi écrire tout ce qu'on veut en Brainfuck, c'est Turing-complet.
La question est, à quel coût ? Si on peut faire la même chose bien plus simplement, de manière plus déterministe, plus rigoureuse et plus concise, je ne comprends vraiment pas l'argument pour s'en priver.
Il n'y a pas de DAG de commits dans Pijul, juste des ensembles de patchs.
C'est pourtant écrit dans la doc existante des dizaines de fois, je l'ai redit dans mon commentaire plus haut, c'est partout dans toute notre communication, et dans les tutoriels contribués par d'autres. Je doute que des tutoriels supplémentaires changent quoi que ce soit.
Oui, moi aussi je m'en fous, mais on nous l'a demandé. Apparemment tout le monde n'a pas les mêmes intérêts.
Je ne suis pas sûr de comprendre. Pourquoi tu ne peux pas simplement faire
pijul add,pijul statusoupijul logpour voir ça ?Si tu juges utile d'avoir ça dans la doc, tu es le bienvenue pour faire un patch du manuel:
https://nest.pijul.com/pijul_org/manual
C'est utile dans Git (je le fais souvent) parce que Git peut parfois déconner complètement quand il merge, et on veut pouvoir examiner le patch avant parce qu'on sait qu'on aura du mal à revenir en arrière. Dans Pijul, ce n'est pas implémenté, mais je doute franchement de l'utilité, parce que (1) Pijul a un algo de merge correct et (2) on peut toujours revenir en arrière, dans 100% des cas.
pijul tagexiste pourtant, c'est dans la doc.Dans la FAQ, il y a un paragraphe sur la navigation dans les versions. C'est plus subtile dans Pijul que dans Git, parce que Git est séquentiel, mais ce n'est pas non plus la mort dans Pijul. C'est même un peu plus flexible, puisqu'on peut composer une version avec seulement certains patchs.
Pour l'instant, on s'en sort à coups d'unrecord (la commande qui enlève des patchs). Pour le futur, on réfléchit à une interface plus efficace, qui tirerait partie de la puissance des ensembles de patchs, tout en restant au moins aussi simple que
git checkout.Pour --recursive, c'est pourtant dans la doc : https://pijul.org/manual/reference/add.html
Pour .gitignore, ce n'est pas dans la doc, mais c'est dans ce tutoriel : https://nest.pijul.com/tae/pijul-for-git-users
Je veux bien répondre à des questions sur des exemples "concrets", encore faut-il me donner ces exemples. Pourquoi les branches et commits dessinés en ascii art constituent des exemples concrets, et ma réponse non ?
Je te suggère de cliquer sur l'onglet "documentation" de https://pijul.org, il conduit là : https://pijul.org/manual/
Il y a déjà de la doc, à laquelle on peut contribuer, poser des questions, etc. C'est un projet open source.
Si l'objectif est de comprendre, lire la doc existante et poser des questions peut aider. Si l'objectif est de se convaincre et de convaincre les autres que Git est mieux, lire la doc de Pijul ne sert pas forcément.
Je ne doute d'ailleurs pas du tout que Git soit mieux dans plein de cas, et pour plein de gens.