la rigueur intellectuelle ne semble pas être une priorité pour certains.
En effet, ceux qui ne restent pas dans la théorie s'intéressent au pragmatisme et préfèrent adopter des outils qui font le job.
C'est d'ailleurs une des forces de Git. Je me souviens de tous ces innombrables VCS (systèmes de contrôles de version :) qui se targuaient de gérer mieux que quiconque le"rename tracking" en le rendant explicite et qui se sont ramassés sur les cas tordus.
Avant que tu ne m'objectes de parler chinois, je te renvoie ici (cherche le terme Merge file renames): https://en.wikipedia.org/wiki/Comparison_of_version-control_software
En gros, comment se débrouille un merge entre 2 branches lorsque le fichier est renommé ?
Il faut détecter que le fichier a été renommé pour appliquer le merge plutôt que de créer un nouveau fichier.
Certains VCS conservent la trace des renommages explicites.
Git a fait un choix différent. Il utilise une de ces "heuristiques" tant décriées par certains.
Il compare simplement le contenu du fichier et considère qu'il a été renommé si le contenu est semblable.
Oh mon dieu, quelle horreur! Ca marche pour 95% des cas mais ce n'est pas mathématiquement prouvé.
Tu peux même ajuster le taux de recouvrement pour tes besoins (find-renames: https://git-scm.com/docs/git-merge)
Seulement voilà, les autres VCS partisans de la stratégie explicite s'y sont cassés les dents parce que dans les cas tordus, ça foire. Au hasard (SVN, Mercurial, Bazar, Monotone, ...)
Il y a même eu un wiki pour répertorier tous ça. Il est down maintenant mais un petit gars a essayé de le sauver. https://github.com/tonyg/revctrl.org
Honnêtement, si tu penses réellement m'avoir tendu un piège, de quelque forme qu'il soit, il faudra que tu me montres où il se trouve.
Je me corrige:
(et que j'ai complété, c'est plutôt moi qui ME LE SUIS tendu le piège)
C'est moi qui ai développé ton graphe pour montrer le cas qui pose pb, il me semble.
Maintenant, si tu acceptes d'utiliser un ton à peine moins condescendant, on pourrait peut-être reprendre le fil de la conversation et tu pourrais peut-être répondre à la question au lieu de tourner autour du pot:
on n'a toujours pas vu un cas où la commutation de patchs aurait ce comportement attendu.
Si on prend aussi le temps de répondre, ce n'est pas forcément pour "démonter" Pijul. Bien au contraire. Et je serai le 1er à m'enthousiasmer pour le challenger qui enterrera Git (Plusieurs pourraient en témoigner ici)
[^] # 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é à 1.
Pardon, c'est un terme assez usuel dans l'industrie logicielle: https://fr.wikipedia.org/wiki/Gestion_de_configuration_logicielle
qui fait même l'objet de normes:
https://blog.ansi.org/2017/05/configuration-management-iso-100072017/
https://www.boutique.afnor.org/standard/ieee-828/configuration-management-in-systems-and-software-engineering-note-approved-2012年02月06日-ieee/article/800191/us044653
En effet, ceux qui ne restent pas dans la théorie s'intéressent au pragmatisme et préfèrent adopter des outils qui font le job.
C'est d'ailleurs une des forces de Git. Je me souviens de tous ces innombrables VCS (systèmes de contrôles de version :) qui se targuaient de gérer mieux que quiconque le"rename tracking" en le rendant explicite et qui se sont ramassés sur les cas tordus.
Avant que tu ne m'objectes de parler chinois, je te renvoie ici (cherche le terme Merge file renames):
https://en.wikipedia.org/wiki/Comparison_of_version-control_software
En gros, comment se débrouille un merge entre 2 branches lorsque le fichier est renommé ?
Il faut détecter que le fichier a été renommé pour appliquer le merge plutôt que de créer un nouveau fichier.
Certains VCS conservent la trace des renommages explicites.
Git a fait un choix différent. Il utilise une de ces "heuristiques" tant décriées par certains.
Il compare simplement le contenu du fichier et considère qu'il a été renommé si le contenu est semblable.
Oh mon dieu, quelle horreur! Ca marche pour 95% des cas mais ce n'est pas mathématiquement prouvé.
Tu peux même ajuster le taux de recouvrement pour tes besoins (find-renames: https://git-scm.com/docs/git-merge)
Seulement voilà, les autres VCS partisans de la stratégie explicite s'y sont cassés les dents parce que dans les cas tordus, ça foire. Au hasard (SVN, Mercurial, Bazar, Monotone, ...)
Il y a même eu un wiki pour répertorier tous ça. Il est down maintenant mais un petit gars a essayé de le sauver.
https://github.com/tonyg/revctrl.org
Je me corrige:
C'est moi qui ai développé ton graphe pour montrer le cas qui pose pb, il me semble.
Maintenant, si tu acceptes d'utiliser un ton à peine moins condescendant, on pourrait peut-être reprendre le fil de la conversation et tu pourrais peut-être répondre à la question au lieu de tourner autour du pot:
Si on prend aussi le temps de répondre, ce n'est pas forcément pour "démonter" Pijul. Bien au contraire. Et je serai le 1er à m'enthousiasmer pour le challenger qui enterrera Git (Plusieurs pourraient en témoigner ici)
Tiens pour le fun:
https://linuxfr.org/users/minimock/journaux/git-a-fete-ses-10-ans-hier