C'est comme affirmer "un dessin est plus intuitif qu'un crayon". C'est du moins comme ça que je perçois cette phrase.
Je te suggère d'imaginer que tes interlocuteurs ne sont pas en train de délirer, et essaient vraiment de proposer un truc autre qu'un changement de vocabulaire.
Un commit, c'est une transaction, exactement comme pour une base de données. Un snapshot, c'est comme pour une VM: un cliché, un instantané. Un patch, c'est un correctif.
Ok, on va donc parler vocabulaire : un patch pour nous, c'est un ensemble de changements quelconque. On pourrait aussi dire un "diff". Laisser tomber tes préjugés deux minutes le temps de lire la dépêche aurait suffi à s'en rendre compte.
leur compréhension est assez aisée.
Non, plein d'utilisateurs de Git pensent que Git travaille avec des diffs, et ne comprennent pas toujours son comportement à cause de ça. Les commits ne sont "assez aisés" à comprendre que quand ils sont simples, qu'il n'y a pas ni conflits ni nécessité de rebaser.
tout ce qui m'intéresse, c'est, par exemple:
J'ai l'impression qu'on a les mêmes intérêts, et que c'est même pour ça que je pense qu'on peut faire mieux que Git:
est-ce que je peux l'apprendre tout seul comme un grand et l'utiliser?
Je rajouterais "en un temps raisonnable". Pour ça je prétends que travailler avec des diffs/patchs est largement plus facile à apprendre, d'abord parce qu'il y a un concept de moins (les commits), et surtout parce que le concept qui reste (les diffs) est très intuitif et très souple à utiliser (et d'ailleurs, c'est ce que Git montre à l'utilisateur).
est-ce qu'il me sauvegarde mes modif's sans me prendre la tête?
Git le fait souvent, pas toujours. Parfois il ne sauvegarde pas que tu as résolu un conflit, et te le remontre plus tard. Parfois il mélange tes additions avec celles de tes coauteurs. Parfois il supprime carrément toute une série d'additions parce que tu as voulu inverser juste un merge et envoyer l'inversion à tes coauteurs.
Pijul a été conçu pour n'avoir aucun de ces problèmes.
est-ce qu'il me fournit un historique de ce que j'ai fait?
Git est en effet super fort là-dessus, sauf qu'il en oublie un petit morceau (l'ordre dans lequel tu as travaillé localement après un merge). Pijul s'en rappelle
est-ce qu'il me permet de naviguer dans mes révisions?
Git ne sait naviguer que linéairement. Par exemple, si tu as fusionné une feature A puis une feature B sur ta branche master, avant de faire un commit C, et que les trois sont indépendants, tu ne peux pas simplement et facilement produire une version qui n'a que A et C.
est-ce qu'il me permet de défaire ce que j'ai fait?
Dans Git, pas toujours comme tu voudrais. En local, tu peux toujours. Si tu veux propager l'inverse d'un merge par exemple, c'est moins clair. Certes, si tu travailles tout seul, que tes branches sont relativement simples, tout va marcher, mais c'est dans les cas pourris qu'on a besoin d'un outil solide.
Pijul n'a pas ce problème, tous les patchs ont un unique inverse (et Pijul n'a que des patchs).
est-ce que je peux récupérer des modif's, individuelles ou groupées?
Dans Git, pas vraiment. Tu peux les "récupérer", mais pas les manipuler librement, pour une contrainte purement technique de Git : la raison pour laquelle Git force l'utilisateur à lui présenter un DAG de commits est simplement que les algos de merge qu'il connaît ne savent travailler que comme ça.
Donc si tu veux "récupérer" tes modifs, et les envoyer par exemple par mail, il faut d'abord les convertir en diff, et appliquer le diff dans de bonnes conditions, avant de tenter une fusion qui ne marche pas dans 100% des cas.
Avec ça, si je ne connais pas la commande, je sais que je peux la trouver sur internet.
Ok, je dois reconnaître que si tu as le temps et l'envie de faire ça, je suis un peu jaloux.
En fait je me moque pas mal que la commande ne soit pas intuitive car je n'ai pas besoin de me souvenir de toutes les commandes disponibles. J'ai les pages du manuel
Perso, je n'ai rien vu (rien cherché non plus, j'avoue), jusqu'à présent, qui me détourne de Git.
Je reconnais qu'il y a une certaine fierté à maîtriser un outil difficile à utiliser. Je suis moi-même content quand j'arrive à aller au bout d'un git rebase compliqué avec plusieurs co-auteurs, en prenant les changements de tout le monde en minimisant les conflits futurs.
Si tu aimes tes outils, c'est très bien ! C'est important pour bien travailler. Est-ce que ça veut dire que les gens qui ne s'en satisfont pas, ou qui préfèrent passer leur temps sur autre chose, sont nuls ? Je ne pense pas.
[^] # 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é à 9.
Je te suggère d'imaginer que tes interlocuteurs ne sont pas en train de délirer, et essaient vraiment de proposer un truc autre qu'un changement de vocabulaire.
Ok, on va donc parler vocabulaire : un patch pour nous, c'est un ensemble de changements quelconque. On pourrait aussi dire un "diff". Laisser tomber tes préjugés deux minutes le temps de lire la dépêche aurait suffi à s'en rendre compte.
Non, plein d'utilisateurs de Git pensent que Git travaille avec des diffs, et ne comprennent pas toujours son comportement à cause de ça. Les commits ne sont "assez aisés" à comprendre que quand ils sont simples, qu'il n'y a pas ni conflits ni nécessité de rebaser.
J'ai l'impression qu'on a les mêmes intérêts, et que c'est même pour ça que je pense qu'on peut faire mieux que Git:
Je rajouterais "en un temps raisonnable". Pour ça je prétends que travailler avec des diffs/patchs est largement plus facile à apprendre, d'abord parce qu'il y a un concept de moins (les commits), et surtout parce que le concept qui reste (les diffs) est très intuitif et très souple à utiliser (et d'ailleurs, c'est ce que Git montre à l'utilisateur).
Git le fait souvent, pas toujours. Parfois il ne sauvegarde pas que tu as résolu un conflit, et te le remontre plus tard. Parfois il mélange tes additions avec celles de tes coauteurs. Parfois il supprime carrément toute une série d'additions parce que tu as voulu inverser juste un merge et envoyer l'inversion à tes coauteurs.
Pijul a été conçu pour n'avoir aucun de ces problèmes.
Git est en effet super fort là-dessus, sauf qu'il en oublie un petit morceau (l'ordre dans lequel tu as travaillé localement après un merge). Pijul s'en rappelle
Git ne sait naviguer que linéairement. Par exemple, si tu as fusionné une feature A puis une feature B sur ta branche master, avant de faire un commit C, et que les trois sont indépendants, tu ne peux pas simplement et facilement produire une version qui n'a que A et C.
Dans Git, pas toujours comme tu voudrais. En local, tu peux toujours. Si tu veux propager l'inverse d'un merge par exemple, c'est moins clair. Certes, si tu travailles tout seul, que tes branches sont relativement simples, tout va marcher, mais c'est dans les cas pourris qu'on a besoin d'un outil solide.
Pijul n'a pas ce problème, tous les patchs ont un unique inverse (et Pijul n'a que des patchs).
Dans Git, pas vraiment. Tu peux les "récupérer", mais pas les manipuler librement, pour une contrainte purement technique de Git : la raison pour laquelle Git force l'utilisateur à lui présenter un DAG de commits est simplement que les algos de merge qu'il connaît ne savent travailler que comme ça.
Donc si tu veux "récupérer" tes modifs, et les envoyer par exemple par mail, il faut d'abord les convertir en diff, et appliquer le diff dans de bonnes conditions, avant de tenter une fusion qui ne marche pas dans 100% des cas.
Ok, je dois reconnaître que si tu as le temps et l'envie de faire ça, je suis un peu jaloux.
Les pages du manuel de Git, vraiment ? Il en existe même des parodies : https://git-man-page-generator.lokaltog.net/
Je reconnais qu'il y a une certaine fierté à maîtriser un outil difficile à utiliser. Je suis moi-même content quand j'arrive à aller au bout d'un
git rebasecompliqué avec plusieurs co-auteurs, en prenant les changements de tout le monde en minimisant les conflits futurs.Si tu aimes tes outils, c'est très bien ! C'est important pour bien travailler. Est-ce que ça veut dire que les gens qui ne s'en satisfont pas, ou qui préfèrent passer leur temps sur autre chose, sont nuls ? Je ne pense pas.