[...] les patchs sont plus intuitifs que les commits [...]
Euh... pardon? Je ne comprends pas cette affirmation. C'est comme affirmer "un dessin est plus intuitif qu'un crayon"
Non, tu penses que « cette discussion focalise un peu trop sur le vocabulaire par rapport aux fonctionnalités » mais tu ne cherches ni à comprendre pourquoi l’auteur fait une différence dans son vocabulaire ni à voir en quoi cette différence est à l’image des objets différents que manipulent Git et Pijul. Un « commit » au sens de Git, c’est un enregistrement de l’état complet de l’espace de travail (un « snapshot », un « cliché » pour reprendre ta liste de synonymes). Un « patch » au sens de Pijul, c’est un ensemble de modifications à l’état de l’espace de travail.
Des modifications qui ne se marchent pas sur les pieds les unes des autres peuvent donc commuter dans Pijul. Git, pour afficher des patchs, recalcule en fait le différentiel entre deux commits mais il ne connaît qu’une liste d’états (les commits) qui évidemment eux ne commutent pas. Cette différence fondamentale est la cause qui fait que dans Git, quand tu rebases une branche sur une autre et que tu résous des conflits, si tu rebases une deuxième fois, tu risques de devoir résoudre à nouveau les mêmes conflits.
Et pour faire court, oui « les patchs sont plus intuitifs que les commits », d’ailleurs Git affiche bien des patchs (même s’il stocke des commits) et un bon commit qui respecte les bonnes pratiques regroupe un ensemble de modifications cohérentes pour apporter une fonctionnalité ou résoudre un bogue. C’est donc bien un objet patch que la programmeuse veut manipuler, et les rouages internes de Git lui montrent de temps en temps que ce n’est pas le cas en la forçant à gérer les conflits de manière non-optimale.
[^] # Re: Soit j'ai rien compris soit...
Posté par jyes . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 8.
Non, tu penses que « cette discussion focalise un peu trop sur le vocabulaire par rapport aux fonctionnalités » mais tu ne cherches ni à comprendre pourquoi l’auteur fait une différence dans son vocabulaire ni à voir en quoi cette différence est à l’image des objets différents que manipulent Git et Pijul. Un « commit » au sens de Git, c’est un enregistrement de l’état complet de l’espace de travail (un « snapshot », un « cliché » pour reprendre ta liste de synonymes). Un « patch » au sens de Pijul, c’est un ensemble de modifications à l’état de l’espace de travail.
Des modifications qui ne se marchent pas sur les pieds les unes des autres peuvent donc commuter dans Pijul. Git, pour afficher des patchs, recalcule en fait le différentiel entre deux commits mais il ne connaît qu’une liste d’états (les commits) qui évidemment eux ne commutent pas. Cette différence fondamentale est la cause qui fait que dans Git, quand tu rebases une branche sur une autre et que tu résous des conflits, si tu rebases une deuxième fois, tu risques de devoir résoudre à nouveau les mêmes conflits.
Et pour faire court, oui « les patchs sont plus intuitifs que les commits », d’ailleurs Git affiche bien des patchs (même s’il stocke des commits) et un bon commit qui respecte les bonnes pratiques regroupe un ensemble de modifications cohérentes pour apporter une fonctionnalité ou résoudre un bogue. C’est donc bien un objet patch que la programmeuse veut manipuler, et les rouages internes de Git lui montrent de temps en temps que ce n’est pas le cas en la forçant à gérer les conflits de manière non-optimale.