• [^] # Re: Difference Pijul vs Git

    Posté par . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 0.

    En effet, surtout s'il est mal compris !

    ... et je n'ai toujours pas d'exemple en dehors de ce qui est considéré comme des mauvaise pratiques: commuter des patches (donc réécrire l'historique) ou encore faire des rebase après merge.

    Pour avoir une UI de bonne qualité, fiable et portable, je suis même allé jusqu'à écrire une implémentation du protocole SSH en Rust !

    Gné ? On ne serait pas dans le syndrome du "not done here" ?

    Quelqu'un qui pose la question a apparemment ça à penser.

    Je n'ai pas posé de question sur la théorie, je demande: concrètement, dans le cycle de vie d'un logiciel, quel problème pijul est censé résoudre ?

    Tiens, je vais commencer. Mon workflow git (assez classique je pense):
    * une branche master
    * nouvelle feature/bugfix: création d'une nouvelle branche, feature/X par exemple
    * rebase régulièrement sur master
    * quand ma feature est prête, merge de feature/X dans master
    * sur master, j'ai bien un commit merge qui me permet de tracer quand la branche a été fusionnée

    La plupart des problèmes que je rencontre aujourd'hui sont liés au merge, effectivement. Il me semble que la plupart du temps, des patchs sémantiques régleraient le problème, par exemple quand il les patchs concernent du coding style, du refactoring, etc. D'ailleurs, j'ai cru comprendre que vous avez d'abord essayé d'améliorer git. git est-il si lié que ça au couple diff/patch ?

    Suis-je donc le seul à rencontrer ces problèmes ? Pijul le résout-il ? Quel problème concret résout Pijul ?

    "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier