Ce genre de soucis est supposé être repéré par les tests unitaires et/ou les participants aux revues de code. Honnêtement, ce genre de cas se produit très rarement en java parce qu'il n'y a pas un pan énorme du langage et des libs qui permette de faire des choses stupides dans ce genre, les effacements de types et autres joyeusetés.
Effectivement, un merge git peut donner des incohérences vu que git gère les conflits fichier par fichier. Ça ne veut aucunement dire que l'ensemble est fonctionnel, seuls des tests peuvent le prouver.
Sur le côté cohérence de git, git n'oblige pas à être cohérent sur le repo, car on considère que ce n'est pas son travail. Les commits et les branches, c'est le travail des développeurs et intégrateurs. Git ne force pas de workflow spécial ou de logique, d'où la prolifération des workflows d'utilisation de git. Si le graphe des commits ne ressemble à rien sous git, faut disputer les devs qui n'y prêtent pas attention. Exemple concret : l'équivalent d'un svn update est un git pull --rebase et il faut donc éduquer les devs sur la bonne commande à utiliser pour ne pas pourrir l'historique.
Pour en revenir à pijul, malgré leurs bonnes idées, j'ai du mal à lui trouver des atouts suffisants. C'est dommage que sa doc se focalise sur un avantage futile (youpi, mes merges sont supposément plus fiables) plutôt que sur des avantages concrets dans 100% des cas (mon repo est 100% fiable, validable et ne peut pas techniquement être corrompu sans rattrapage possible).
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par damaki . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 3.
Ce genre de soucis est supposé être repéré par les tests unitaires et/ou les participants aux revues de code. Honnêtement, ce genre de cas se produit très rarement en java parce qu'il n'y a pas un pan énorme du langage et des libs qui permette de faire des choses stupides dans ce genre, les effacements de types et autres joyeusetés.
Effectivement, un merge git peut donner des incohérences vu que git gère les conflits fichier par fichier. Ça ne veut aucunement dire que l'ensemble est fonctionnel, seuls des tests peuvent le prouver.
Sur le côté cohérence de git, git n'oblige pas à être cohérent sur le repo, car on considère que ce n'est pas son travail. Les commits et les branches, c'est le travail des développeurs et intégrateurs. Git ne force pas de workflow spécial ou de logique, d'où la prolifération des workflows d'utilisation de git. Si le graphe des commits ne ressemble à rien sous git, faut disputer les devs qui n'y prêtent pas attention. Exemple concret : l'équivalent d'un svn update est un git pull --rebase et il faut donc éduquer les devs sur la bonne commande à utiliser pour ne pas pourrir l'historique.
Pour en revenir à pijul, malgré leurs bonnes idées, j'ai du mal à lui trouver des atouts suffisants. C'est dommage que sa doc se focalise sur un avantage futile (youpi, mes merges sont supposément plus fiables) plutôt que sur des avantages concrets dans 100% des cas (mon repo est 100% fiable, validable et ne peut pas techniquement être corrompu sans rattrapage possible).