Déjà, que git utilise en interne autre chose que ce que je vois, peu importe: en tant qu'utilisateur, c'est ce que je vois qui m'importe.
C'est un peu faux : si Git te montre des patchs, c'est qu'il sait qu'on a du mal à travailler avec autre chose !
Si les patchs étaient une représentation fidèle, dans 100% de cas, de ce qu'il y a dessous, ton commentaire serait vrai : d'ailleurs Pijul représente sa structure interne de manière un peu tordue, mais cette représentation est en bijection avec l'ensemble des patchs appliqués dans le dépôt.
Ce n'est pas le cas dans Git, où certains commits ne sont pas représentables par des patchs (des commits de fusion de branches, de résolution de conflits...).
La différence est loin d'être anecdotique : c'est justement dans les cas difficiles qu'on a besoin d'un bon système de contrôle de versions intuitif et déterministe, pas quand tout va bien, que l'historique est linéaire, qu'il n'y a jamais ni conflits ni rebases ni fusions.
La belle affaire: ça ne m'intéresse pas, bien au contraire.
Je n'y crois pas trop : sauf si tu utilises Git seulement dans ton coin en travaillant sur un seul bout de ton code à la fois, tu essaies de simuler la commutativité tout le temps avec Git, en utilisant des feature branches. Parfois ça marche, parfois il faut passer un temps plus ou moins important à rebaser.
Par exemple, plein d'utilisateurs un peu expérimentés de Git ont des astuces pour utiliser autre chose que git pull (qui vont de git pull --rebase à git fetch + git merge, et autres git rerere s'il y a un conflit), simplement parce qu'ils savent qu'ils ne vont plus jamais pouvoir faire commuter quoi que ce soit une fois le commit terminé.
La qualité et la sécurité du code exige que l'historique des sources soit immuable.
En fait "dans la vraie vie" c'est plus compliqué que ça. Dans Git, l'historique des sources devient artificiel à partir du moment où on rebase des trucs, ce qui arrive assez souvent quand on travaille à plusieurs, et/ou sur un projet un peu gros ou un peu compliqué. En forçant un historique identique pour tout le monde, Git oublie l'ordre local dans lequel on a travaillé, et oublie les relations de dépendances.
En plus, en forçant un historique séquentiel sur une branche donnée, Git force son utilisateur à organiser son travail en amont, alors qu'on sait bien qu'on ne travaille pas toujours sur du code selon un ordre établi à l'avance, en particulier quand on cherche à corriger un bug.
Si on parle de sécurité, je ne trouve pas très sécurisant d'avoir un algo de merge (tous ceux de Git ont ce problème) qui peut mélanger des lignes venant des deux branches un peu aléatoirement. Par contre, je serais content de pouvoir virer un vieux patch qui avait introduit une faille de sécurité, tout en gardant ce que j'ai fait après.
En résumé, je pense que "La qualité et la sécurité du code exigent":
- que les algos qui manipulent le code soient déterministes, prévisibles, et qu'on puisse les inverser si on fait une erreur. Git n'a aucune de ces propriétés à 100% (mais essaie de les avoir assez souvent).
- qu'on puisse savoir exactement ce qu'on envoie en production. Mais il n'y a pas besoin de version immutables tout le long du développement pour ça, bien au contraire, il suffit de pouvoir identifier un truc qui fonctionne.
[^] # 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é à 7.
C'est un peu faux : si Git te montre des patchs, c'est qu'il sait qu'on a du mal à travailler avec autre chose !
Si les patchs étaient une représentation fidèle, dans 100% de cas, de ce qu'il y a dessous, ton commentaire serait vrai : d'ailleurs Pijul représente sa structure interne de manière un peu tordue, mais cette représentation est en bijection avec l'ensemble des patchs appliqués dans le dépôt.
Ce n'est pas le cas dans Git, où certains commits ne sont pas représentables par des patchs (des commits de fusion de branches, de résolution de conflits...).
La différence est loin d'être anecdotique : c'est justement dans les cas difficiles qu'on a besoin d'un bon système de contrôle de versions intuitif et déterministe, pas quand tout va bien, que l'historique est linéaire, qu'il n'y a jamais ni conflits ni rebases ni fusions.
Je n'y crois pas trop : sauf si tu utilises Git seulement dans ton coin en travaillant sur un seul bout de ton code à la fois, tu essaies de simuler la commutativité tout le temps avec Git, en utilisant des feature branches. Parfois ça marche, parfois il faut passer un temps plus ou moins important à rebaser.
Par exemple, plein d'utilisateurs un peu expérimentés de Git ont des astuces pour utiliser autre chose que
git pull(qui vont degit pull --rebaseàgit fetch+git merge, et autresgit rereres'il y a un conflit), simplement parce qu'ils savent qu'ils ne vont plus jamais pouvoir faire commuter quoi que ce soit une fois le commit terminé.En fait "dans la vraie vie" c'est plus compliqué que ça. Dans Git, l'historique des sources devient artificiel à partir du moment où on rebase des trucs, ce qui arrive assez souvent quand on travaille à plusieurs, et/ou sur un projet un peu gros ou un peu compliqué. En forçant un historique identique pour tout le monde, Git oublie l'ordre local dans lequel on a travaillé, et oublie les relations de dépendances.
En plus, en forçant un historique séquentiel sur une branche donnée, Git force son utilisateur à organiser son travail en amont, alors qu'on sait bien qu'on ne travaille pas toujours sur du code selon un ordre établi à l'avance, en particulier quand on cherche à corriger un bug.
Si on parle de sécurité, je ne trouve pas très sécurisant d'avoir un algo de merge (tous ceux de Git ont ce problème) qui peut mélanger des lignes venant des deux branches un peu aléatoirement. Par contre, je serais content de pouvoir virer un vieux patch qui avait introduit une faille de sécurité, tout en gardant ce que j'ai fait après.
En résumé, je pense que "La qualité et la sécurité du code exigent":
- que les algos qui manipulent le code soient déterministes, prévisibles, et qu'on puisse les inverser si on fait une erreur. Git n'a aucune de ces propriétés à 100% (mais essaie de les avoir assez souvent).
- qu'on puisse savoir exactement ce qu'on envoie en production. Mais il n'y a pas besoin de version immutables tout le long du développement pour ça, bien au contraire, il suffit de pouvoir identifier un truc qui fonctionne.