Tout ce que tu décris en terme de réorganisation est possible avec le rebase de Git.
Si j'essaie de comprendre ce que que tu exprimes:
Avec une vision "ensembliste" des patchs, on peut ré-agencer comme on le souhaite. La souplesse et la consistance seraient au rendez-vous car tout ceci est "mathématiquement" prouvé. Soit!
Le fait de ne pas ré-appliquer les commits (cherry-pick) est un plus car il conserve l'identité des patchs. Ok. (J'imagine que tu réarranges le graphe des patches en modifiant les arcs).
Pourtant, tu ne nies pas que seuls les patchs produits en // commutent. J'ai vraiment du mal à comprendre.
Par ailleurs, une petite critique au passage sur la documentation (Je sais que c'est encore en version alpha):
D'une manière générale, elle mélange les concepts et l'interface.
En tant qu'utilisateur, le format du repo m'importe peu (https://pijul.org/manual/format.html) . Par contre, voir à quoi ressemble la sortie d'une commande comme "add" "status" ou "log" m'apporterait.
pijul pull --from-branch A --to-branch B a1 A1 a2 A2 a3 A3 Là, tu inclues les ids de commits. Tu voulais peut-être écrire:
pijul pull --from-branch A --to-branch B a1 a2 a3 Nous sommes en local dans le même repo.
La doc de "pull" indique que la commande concerne la synchronisation avec des repo distants https://pijul.org/manual/reference/pull.html. Le pull prend en charge la fusion aussi ?
D'autres choses m'interrogent (on peut mettre ça sur le compte de la maturité du projet , j'imagine).
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.
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.
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 ?
Je ne vais pas te donner les exemples avec des diffs (mais tu ne me les donne pas non plus pour Git).
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". 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.
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2. Dernière modification le 06 mai 2019 à 14:16.
Tout ce que tu décris en terme de réorganisation est possible avec le rebase de Git.
Si j'essaie de comprendre ce que que tu exprimes:
Avec une vision "ensembliste" des patchs, on peut ré-agencer comme on le souhaite. La souplesse et la consistance seraient au rendez-vous car tout ceci est "mathématiquement" prouvé. Soit!
Le fait de ne pas ré-appliquer les commits (cherry-pick) est un plus car il conserve l'identité des patchs. Ok. (J'imagine que tu réarranges le graphe des patches en modifiant les arcs).
Pourtant, tu ne nies pas que seuls les patchs produits en // commutent. J'ai vraiment du mal à comprendre.
Par ailleurs, une petite critique au passage sur la documentation (Je sais que c'est encore en version alpha):
D'une manière générale, elle mélange les concepts et l'interface.
En tant qu'utilisateur, le format du repo m'importe peu (https://pijul.org/manual/format.html) . Par contre, voir à quoi ressemble la sortie d'une commande comme "add" "status" ou "log" m'apporterait.
pijul pull --from-branch A --to-branch B a1 A1 a2 A2 a3 A3
pijul pull --from-branch A --to-branch B a1 a2 a3
La doc de "pull" indique que la commande concerne la synchronisation avec des repo distants
https://pijul.org/manual/reference/pull.html. Le pull prend en charge la fusion aussi ?
D'autres choses m'interrogent (on peut mettre ça sur le compte de la maturité du projet , j'imagine).
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.
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.
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". 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.
Je précise que ceci n'est pas une attaque.