Il faut qu'on devine ton raisonnement puis qu'on devine ce en quoi ce que dis la personne qui essaie de te répondre ne réponds pas à ce que tu voulais dire ?
Quand tu ne comprends pas un message et que tu le sais, tu ne penses pas à demander des explications avant de juger? Genre: «que veux-tu dire exactement?»
Ce genre de stratégie me semble bien peu productif.
Hélas, ce n'est pas tout-à-fait vrai. C'est le même fondement que celui dont se servent les platistes, entre autres: il y aura toujours des ignares (pour rester poli) pour continuer à propager la merde intellectuelle.
Ton raisonnement qui est « c'est pas bien de faire du tris automatique de bug » ?
Raté, ce n'est pas mon raisonnement.
Le raisonnement est: arriver à un point (ou volume de bugs) tel qu'on ait besoin d'une intelligence artificielle pour les gérer est probablement symptomatique. Je te laisse deviner de quoi. Pas envie de m'étendre là dessus.
PS: sans avoir beaucoup chercher non plus, il ne me semble pas y avoir une GUI pour lvm, depuis le temps..
Les distributions incluent en général, dans leur phase d'installation, un GUI pour LVM. Certes, sorti de l'installation, exit aussi l'interface graphique.
Une loi ne sert à rien. Notre responsabilité est collective de ne pas utiliser les services qui ne correspondent pas à une logique d'interopérabilité. De toutes façons, loi ou pas, c'est déjà mal parti vu que la majeure partie des utilisateurs se contrefout de l'interopérabilité¹… sinon ce serait déjà fait, auquel cas il n'y aurait pas besoin de loi.
¹ Y a qu'à demander autour de nous. Qui parmi eux sait même ce qu'est l'interopérabilité?
Une IA pour corriger les bugs dans des programmes… Il y a quelque chose qui me… comment dire… («ça vous chatouille? ou ça vous grattouille?»)
C'est moi ou on va un peu loin, là? Pourquoi pas inventer une IA qui agirait génétiquement sur les humains pour qu'ils soient capables d'écrire des programmes sans bug? Ah ouais, mais alors on n'aurait plus besoin des IA. C'est con. Y a plus qu'à faire écrire des programmes par des IA. Ah ouais, ça se fait déjà…
C'est marrant, quand j'ai lu «[…] du stade d’idée à celui de business model […]» j'ai, juste l'espace d'un instant, cru lire «du stade d’idée à celui de business bordel» …
Je ne comprends pas cette obsession autour de git revert et de l'idée d'annuler des patch. J'ai répondu avec une commande du style:
git diff X Y | patch
que personne n'a commenté, non content de ça et qui s'est faite moinsser sans la moindre explication. J'aimerais comprendre, c'est tout.
Ré-écrire l'historique, quelle qu'en soit la raison, dans un projet quel qu'il soit est en effet une très mauvaise idée et le commentaire de barmic explique pourquoi. Alors, je repose ma question, autrement: est-ce qu'il y a quelque chose de dérangeant dans ma suggestion? Et, si oui, pourquoi?
Ta liste donne plutôt des exemples où c'est normal de faire une recherche, soit car on ne peut pas tout connaître - la posologie d'un médicament, soit parce qu'on ne peut pas tout se rappeler - la syntaxe de toutes commandes bash. Il est également normal de faire une recherche quand on est aux limites du scope d'utilisation d'un outil ou dans un cas rare… ou parce qu'on ne connaît pas encore bien l'outil.
Ok. Alors dans ce cas, je ne suis pas d'accord sur la conclusion que tu fais de mes propos. J'ai tenu cette liste comme exemples de raisons pour lesquelles on ne doit pas juger un produit sur le simple fait de devoir faire des recherches, ce qui s'appelle une déduction hâtive. Et j'ajouterais aussi: «même pour des cas triviaux». La mémoire, si on ne tient compte que de ça, ben ça flanche. Que tu considères que ces recherches soient "normales" ou non, est sans rapport avec mon propos.
Le cas des médicaments que tu soulèves est un cas particulier du mien et pour lequel je ne partage pas non plus ton point de vue (à savoir que c'est normal de rechercher dans ce cas là). Que mon exemple te paraisse bancal ne contredit en rien qu'il n'est pas bon de faire des déductions hâtives.
kantien te parlait, lui, d'un cas d'utilisation qu'il considère normal pour un CVS […]
Alors ça tombe bien, je lui ai répondu avec un exemple qui tient en une seule commande. J'espère que tu as vu ma réponse. Dis-moi ce que tu en penses.
[…] à charge pour toi de le démentir là-dessus s'il y a lieu
Hmmm… tu me donne une charge que je ne suis pas forcé d'accepter. Mais bon, j'arrête de pinailler.
Ta question est pertinente et, si c'est à moi que tu poses cette question, je répète, je n'ai pas la solution, n'étant pas non plus un fin connaisseur de Git. Je ne pourrai être certain d'y répondre proprement que lorsque j'aurai du temps à y consacrer.
Ceci dit, on est peut-être en train de chercher midi à quatorze heures. En y réfléchissant quelques secondes de plus, si je te suggères de demander à Git de te renvoyer un patch complet correspondant à la liste des modifications de la branche A (genre git diff ), puis que tu appliques ce patch à "l'envers" (commande patch -r), as-tu ta réponse?
En somme:
git diff a1 a3 > correctif.diff
patch -r < correctif.diff
# ... ensuite les commits d'usage
Voire mieux:
git diff a3 a1 > correctif.diff
patch < correctif.diff
# ... ensuite les commits d'usage
Ou encore:
git diff a3 a1 | patch
# ... ensuite les commits d'usage
L'avantage est que 1) tu n'as pas à annuler quoi que ce soit (c'est quoi "annuler", d'ailleurs?), 2) il n'est pas nécessaire de ré-écrire l'historique (puisque c'est "mal") si le dépôt public a été modifié et 3) tous les dépôts restent cohérents. Au final, je vois ladite annulation comme une opération de plus.
Et on fait ça avec Git en une seule commande et une seule ligne. À condition que j'aie bien compris ta question, cela va de soi. Je n'ai pas parlé de l'argument "--dry-run" avant d'appliquer un correctif mais prudence oblige, bien entendu.
Est-ce que cette proposition répond à ta question?
PS. Comparer le fait d'avoir à chercher sur internet la solution à un problème du type de celui posé par kantien aux exemples de ta liste me paraît assez discutable pour beaucoup d'entre eux.
Je n'ai pas encore eu à traiter le cas que tu soulèves. Je dois aussi avouer que c'est pas tous les jours que j'élimine des branches ;-). Je ne pourrai donc que répondre de manière intuitive, sur base des commandes que je connais.
Je dirais donc, sur base de ces préliminaires, de supprimer les commits de la branche A. Si je ne m'abuse, supprimer une branche revient à supprimer ses commits. Maintenant, vu que la branche a été fusionnée, je n'ai aucune idée de ce que ça donnerait.
En fait, j'en sais foutre rien :-D. En général, je cherche sur internet lorsque le cas se présente. Et ça ne me dérange pas le moins du monde.
Si il faut plus d'une commande, fouiller dans les bonnes pratiques, chercher sur le net pour résoudre une question aussi triviale, alors git (ou autre VCS) a un problème.
Permets-moi de ne pas partager ce point de vue.
Ça m'arrive très souvent de chercher sur internet la syntaxe d'une fonction en C ou en C++.
Ça m'arrive, Ô combien de fois, de chercher sur internet à propos de Python.
Idem pour Git.
Idem pour Linux.
Idem pour bash.
Idem quand je me rends à un endroit que je ne connais pas, je sors mes cartes ou je zieute sur openstreetmap.
Idem quand je prends un médicament pour savoir combien de fois je peux en prendre en une journée (là je lis la notice, œuf corse)
Est-ce que ça veut dire que Python, C, C++, Git, Linux, bash, les médocs, la signalisation routière (ou quoi ou qu'est-ce) ont tous un problème? Ou bien, principe de parcimonie aidant, que je n'ai juste pas une bonne mémoire? Ou bien que je n'utilise pas assez souvent ces ustensiles pour qu'ils me restent en mémoire? Ou que ces outils sont trop complexes pour moi parce qu'ils contiennent plus de variantes ou d'options que ce que j'arrive à retenir? Ou bien parce qu'étant une grosse feignasse, vu que je sais où me documenter, je ne fais pas/plus le moindre effort pour m'en souvenir?
Laquelle de ces explications est la bonne? Peut-être qu'elles le sont toutes?
Tu vois, je ne suis pas aussi catégorique pour juger de ce qu'un outil est bien ou mal fichu. Tout ça relève de l'opinion personnelle dans la plupart des cas. Il y a plus d'une explication pertinente dans pas mal de situations. Le tout est de trouver la plus pertinente. Ça n'est pas toujours facile. Qualifier l'outil est plutôt tentant mais en le faisant, on risque de passer à côté de points bien plus importants, peut-être à côté de l'essentiel.
Git est complexe. Ça, c'est vrai. Trop complexe? C'est bien possible. Mais quand on observe autour de nous, est-ce que "les choses" n'ont pas tendance à se complexifier au point de ne plus pouvoir être maîtrisables par un seul humain? Ne serait-ce pas un signe des temps?
J'en sais rien en fait, je pose juste une question. Enfin, quelque part, si, je me doute. Je me rends compte, notamment, que l'informatique devient de plus en plus complexe et compliquée. Et je pense (c'est mon opinion) que c'est parce que de plus en plus de développeurs n'arrivent pas/plus à apporter des solutions simples à des problèmes simples. Dans beaucoup de cas, j'accepte cette complexité et je fais avec. Dans d'autres cas, je la refuse et je fais tout moi-même. Et parfois, aussi, je baisse les bras et je tourne la page.
Mais bon, je digresse, c'était pas le sujet principal, désolé.
Git a près (plus?) de quatorze ans. Pijul, si j'ai bien lu, a trois ans. Au train où vont les choses, il vaudrait mieux repasser dans une dizaine d'années; on verra bien comment/si l'un et l'autre auront évolués, si notre concept de "simplicité" (et le reste) n'a pas lui non plus évolué…
N.B.: je fais volontairement une différence entre complexe (association d'un grand nombre de choses simples) et compliqué (qu'on a du mal à comprendre, par exemple parce que mal foutu, pas ou peu intuitif, contraire au bon sens…) Donc quelque chose de complexe peut être facile à comprendre, par exemple parce que bien détaillé ou documenté pour chacun de ses sous-ensembles.
Il faut comprendre : Un formalisme patch based est plus intuitif que commit based. Et donc oui c'est comparable et non ce n'est pas une question de vocabulaire. Git stock des commits et pijul des patchs.
Exprimé comme ça, en effet, ça m'éclaire un peu plus sur ce que l'auteur a voulu exprimer concernant ce qui est intuitif ou pas.
Affirmer "moi je fais les choses bien et je n'ai pas de problème avec git, donc si on fait les choses bien il n'y a pas de problème avec git" souffre d'un biais qui me paraît évident.
… sauf que ce n'est pas exactement ce que j'ai dit. Je n'ai pas la prétention de faire les choses bien, j'affirme juste m'inspirer de ceux qui, eux, font bien. Après, je fais de mon mieux et je m'applique.
Ensuite, j'affirme en effet ne pas avoir de problème avec Git et j'explique (en gros) pourquoi. Le reste, «donc si on fait bien les choses bien […]» est une interprétation d'un sous-entendu que je n'ai jamais eu l'intention d'exprimer… et que je n'ai pas exprimé non plus!
Ma litanie est centrée sur une généralisation de la part de l'auteur sur l'inexistence de cette fameuse perception intuitive, ce que je considère excessif (permets-moi un peu de poésie). Et pour réfuter cette affirmation, j'ai tenu le raisonnement suivant, même si je ne l'ai pas détaillé.
La probabilité qu'un développeur lambda rencontre les termes "snapshot", "commit" et "patch" est relativement élevée. On trouve le terme "snapshot" dans le jargon de la virtualisation et de la sauvegarde, les backups. Le terme "commit" se rencontre dans celui des bases de données, notamment. Le "patch" est un terme commun, notamment pour toute personne qui se sert de Linux ayant un jour voulu remonter un bug ou soumettre un correctif (mais pas que).
La probabilité que ces trois termes soient rencontrés par un développeur est relativement élevée. En effet, il n'est pas rare qu'un développeur, dans sa carrière, manipule des bases de données, des machines virtuelles et fasse aussi des backups — c'est à espérer, d'ailleurs! Donc si ces termes sont rencontrés et qu'ils sont bien compris, il ne devrait pas y avoir de confusion.
C'est ça, le raisonnement que j'ai tenu et c'est sur cette seule affirmation (à propos de la perception intuitive) que j'argumentais. Je ne remets en question son produit en aucun cas, bien évidemment.
L'auteur aurait déclaré: «il existe pas mal de monde qui confond patch et commit avec Git, voici pourquoi: …», je n'aurais probablement pas réagi. Peut-être même pas du tout.
Si la dépêche peut être abscons les commentaires ont beaucoup aidé à faire ressortir des cas et à expliquer de diverses façons par plusieurs personnes les impacts du changement de paradigme.
De fait. Je n'ai pas suivi l'affaire depuis mon premier commentaire.
Mais, comme le dis l'auteur, si git te convient c'est parfait.
Merci pour tes explications, dont je retiendrai en essence ceci:
plein d'utilisateurs de Git pensent que Git travaille avec des diffs, et ne comprennent pas toujours son comportement à cause de ça.
C'est effectivement ce qui répond à la question que je n'ai pas posée de manière explicite. J'en déduis donc que tu possèdes de nombreux retours d'utilisateurs pour en être arrivé à cette conclusion. C'eût été intéressant d'en connaître les proportions, ceci dit. Ce n'est pas une critique, je manifeste juste ma curiosité.
J'aimerais revenir sur certains de tes propos. Tout d'abord:
Ok, on va donc parler vocabulaire : un patch pour nous, c'est un ensemble de changements quelconque. On pourrait aussi dire un "diff".
J'en ai exactement la même compréhension.
Ensuite tu reprends et détailles les différents points que j'ai énumérés. Merci pour cet effort d'avoir détaillé l'expérience des autres.
Cependant je n'ai abordé ces points que pour détailler ce qui comptait pour moi… puisque mon commentaire concluait que je n'ai pas encore eu de raison de passer à autre chose [que Git]. Je ne faisais donc que détailler mon expérience personnelle et en quoi je n'ai pas (encore) eu de raison de changer, puisque Git 1) n'a jamais été pour moi source de la confusion dont tu parles et 2) m'apporte une réponse [au moins] satisfaisante à tous les besoins que j'ai énumérés — ce dernier point était implicite, il n'était pas exprimé, c'est vrai.
Mon commentaire partait d'ailleurs de la confusion entre «commit» et «patch», d'accord? C'est sur cette base, agrémentée de plusieurs autres points, que j'ai argumenté pour arriver à la conclusion.
Ok, je dois reconnaître que si tu as le temps et l'envie de [chercher sur internet], je suis un peu jaloux.
J'ai appris à me démerder et je prends toujours le temps d'apprendre à bien faire les choses dès le début auprès de ceux qui ont l'expérience. J'ai toujours été clair là dessus avec mes employeurs. J'investis ce temps pour mes projets personnels, ce qui me permet d'appliquer au boulot ce que j'apprends.
Je suis conscient d'être probablement un privilégié. Mais à partir du moment où je peux me le permettre…
Pour le reste, j'aimerais aborder des points qui ont tendance à m'irriter un tantinet:
Je te suggère d'imaginer que tes interlocuteurs ne sont pas en train de délirer, et essaient vraiment de proposer un truc autre qu'un changement de vocabulaire.
Qu'est-ce qui te fait croire que j'imagine que «mes interlocuteurs» délirent?
Et par «tes interlocuteurs», c'est de toi que tu parles?
Où exactement et en quoi ai-je réduit ton produit à une simple question de vocabulaire?
Puisque tu abordes ce sujet, dois-je en déduire que tu insinues que je délire?
Ça a le style, l'air et les termes d'une attaque personnelle. Tu peux développer, STP?
Tout message est laissé à l'interprétation de celui qui le reçoit et je ne peux être tenu pour responsable de l'interprétation que quiconque fait de mes propos, surtout sur base du texte seul et sans l’intonation ni l'expression de mon visage. Si tu t'es senti blessé par ce que j'ai raconté, ce n'était pas mon intention; si tel est le cas, j'en suis vraiment navré.
Lorsque j'ai mentionné le mot «vocabulaire», je parlais de la discussion, pas de ton produit. Dans tous les cas, un outil vient avec son vocabulaire et son formalisme, qu'il convient d'apprendre et de maîtriser, que l'outil soit informatique ou non. Tu ne partages pas cette analyse?
Si le vocabulaire et le fonctionnement de Git son mal compris, c'est sans doute là qu'il faut agir — et je ne pars pas du principe que tu ne l'as pas fait. Dans ces cas-là, plusieurs possibilités existent: 1) améliorer la documentation et la compréhension des utilisateurs, 2) améliorer le produit pour qu'il soit mieux compris, 3) changer de produit, 4) en créer un nouveau.
Soit dit en passant, créer un nouveau produit ou en changer parce que le premier n'est pas compris par ses utilisateurs ne résoudra pas ce problème en particulier, n'est-ce pas?
Laisser tomber tes préjugés deux minutes le temps de lire la dépêche aurait suffi à s'en rendre compte.
Peux-tu m'indiquer avec précision de quels préjugés tu parles?
Suggères-tu que ma compréhension de la dépêche est baisée?
Si oui, sur quelles informations précises te bases-tu?
Les pages du manuel de Git, vraiment ?
Je n'ai pas mentionné que ça! Pourquoi t'attarder là-dessus uniquement, alors que j'ai clairement indiqué que je me réfère au manuel ET à ce que je trouve sur internet quand ce dernier ne m'aide pas? À part pour faire un appel au ridicule, je ne vois pas l'intérêt d'un tel commentaire.
Est-ce que ça veut dire que les gens qui ne s'en satisfont pas […] sont nuls ?
Ce que tu fais là s'appelle un procès d'intention. Soyons clairs, d'abord tu n'es pas dans ma tête; tu ne peux donc savoir ce que je cherche — ce que j'ai écrit n'en constitue pas l'expression intégrale et tu disposes de trop peu d'information pour te faire une idée rigoureuse de ce que j'ai en tête et de ce que je cherche exactement.
Ensuite, si j'ai proféré cette affirmation, c'est tout simplement pour exprimer que je ne comprends pas celle de l'auteur. Après, que tu te méprennes sur mes intentions, ma foi, je n'ai pas demandé explicitement que l'auteur éclaircisse ses propos, c'est exact. S'il le fait (et c'est d'ailleurs le cas dans son commentaire plus bas), alors tant mieux et merci à lui.
Finalement tu m'expliques ce qu'est un commit pour Git (ce que je sais déjà) et ce qu'est un patch au sens de Pijul. Merci bien, mais ça n'éclaire pas ma lanterne en quoi l'un peut être plus (ou moins) intuitif que l'autre.
Un commit et un patch sont deux choses totalement distinctes, que l'on ne peut comparer — un cliché (ou un commit) est un moyen pour Git d'arriver au résultat souhaité, un patch, le second est donc le résultat du premier. Donc dire que l'un est plus intuitif que l'autre, ça n'a pas de sens pour moi.
Si je suis arrivé à cette conclusion, c'est donc qu'il n'y a aucune ambiguïté en ce qui me concerne — je répète: je parle pour moi, je ne prends pas mon cas pour un généralité. Voilà pourquoi j'ai affirmé ne pas comprendre ce qui amenait l'auteur à dire ça.
[…] 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". C'est du moins comme ça que je perçois cette phrase.
Un commit, c'est une transaction, exactement comme pour une base de données. Un snapshot, c'est comme pour une VM: un cliché, un instantané. Un patch, c'est un correctif. Les trois sont intuitifs, quand on a déjà des références, ce qui ne doit pas être impossible, surtout pour un développeur. Ça ne signifie pas nécessairement que ces termes sont interchangeables mais que leur compréhension est assez aisée.
Sinon, je pense que cette discussion focalise un peu trop sur le vocabulaire par rapport aux fonctionnalités. Qu'on appelle ce "truc" un "patch", un "commit", un "snapshot", quelle importance? Ce que demande un développeur, AMHA, c'est que l'outil fonctionne, qu'il lui donne satisfaction et lui permette de faire ce qu'il désire sans se prendre le chou. Maintenant, que ce soit à travers des "patches", des "commits", des "snapshots", des "branches", des "rebase"… tout ça c'est juste du formalisme à se farcir. Pour tirer le meilleur parti d'un outil, il faut maîtriser son utilisation — oui, le vocabulaire en fait partie.
En ce qui concerne un outil de gestion de code source — je parle pour moi — tout ce qui m'intéresse, c'est, par exemple:
est-ce que je peux l'apprendre tout seul comme un grand et l'utiliser?
est-ce qu'il me sauvegarde mes modif's sans me prendre la tête?
est-ce qu'il me fournit un historique de ce que j'ai fait?
est-ce qu'il me permet de naviguer dans mes révisions?
est-ce qu'il me permet de défaire ce que j'ai fait?
est-ce qu'il me permet de regrouper des changements?
est-ce que je peux récupérer des modif's, individuelles ou groupées?
est-ce qu'il est disponible au moins sur Windows, Linux et Mac, que je puisse partager du code avec n'importe qui?
Avec ça, si je ne connais pas la commande, je sais que je peux la trouver sur internet. En fait je me moque pas mal que la commande ne soit pas intuitive car je n'ai pas besoin de me souvenir de toutes les commandes disponibles. J'ai les pages du manuel et, si vraiment je suis bouché, je trouve sur StackOverflow. Ou ailleurs.
Perso, je n'ai rien vu (rien cherché non plus, j'avoue), jusqu'à présent, qui me détourne de Git. Et il y a beaucoup de cerises sur le git-eau…
A priori Pijul ne donne pas de motif suffisant à changer par rapport à Git. Je pense que c'est l'un des points abordés par Jean Parpaillon dans ses commentaires.
Ceci dit, c'est très bien que des outils comme ça naissent aussi. Après tout, c'est aussi un des [nombreux] aspects du logiciel libre. Avoir plus d'un point de vue, éclairé ou pas, que chacun puisse faire son choix, en toute liberté, c'est bien. Après, c'est la nature [humaine] qui décide ;-) …
La nouvelle disposition AZERTY ressemble pour beaucoup à la disposition «Français (Macintosh)», que j'utilise principalement. Ce sont entre autres les caractères æ, œ, \, |, ~ qui ont des positions similaires voire identiques.
Ce qui les rassemble, c'est le temps que ces personnes investissent pour collecter l'information à la source, la compiler et la résumer pour tous. Chacune d'elles mériterait bien un article. À consommer consulter sans modération…!
Ok, je me corrige: l'EFF ne demande pas explicitement de supprimer les certif's QuoVadis mais explicitement ceux de DarkMatter. C'est l'article de Korben qui est foireux! (ou pute-à-clics, de toutes façons c'est pareil *soupirs*)
[^] # Re: Ça me laisse perplexe...
Posté par FantastIX . En réponse à la dépêche Zoom sur trois projets émergents portés par Mozilla : Fluent, Bugbug et BinaryAST. Évalué à -2.
Quand tu ne comprends pas un message et que tu le sais, tu ne penses pas à demander des explications avant de juger? Genre: «que veux-tu dire exactement?»
[^] # Re: Spam politique
Posté par FantastIX . En réponse au journal Impressions sur la campagne pour les européennes. Évalué à 4.
Hélas, ce n'est pas tout-à-fait vrai. C'est le même fondement que celui dont se servent les platistes, entre autres: il y aura toujours des ignares (pour rester poli) pour continuer à propager la merde intellectuelle.
[^] # Re: Ça me laisse perplexe...
Posté par FantastIX . En réponse à la dépêche Zoom sur trois projets émergents portés par Mozilla : Fluent, Bugbug et BinaryAST. Évalué à -3. Dernière modification le 24 mai 2019 à 16:09.
Raté, ce n'est pas mon raisonnement.
Le raisonnement est: arriver à un point (ou volume de bugs) tel qu'on ait besoin d'une intelligence artificielle pour les gérer est probablement symptomatique. Je te laisse deviner de quoi. Pas envie de m'étendre là dessus.
[^] # Re: dm-cache?
Posté par FantastIX . En réponse à la dépêche Gestion de volumes RAID avec LVM. Évalué à 4.
Les distributions incluent en général, dans leur phase d'installation, un GUI pour LVM. Certes, sorti de l'installation, exit aussi l'interface graphique.
[^] # Re: Ça me laisse perplexe...
Posté par FantastIX . En réponse à la dépêche Zoom sur trois projets émergents portés par Mozilla : Fluent, Bugbug et BinaryAST. Évalué à 0.
Et ça change quoi au raisonnement?
[^] # Re: C'est bien de faire une loi...
Posté par FantastIX . En réponse à la dépêche Appel de plusieurs organisations à imposer un minimum d’interopérabilité pour les GAFA. Évalué à 6.
Une loi ne sert à rien. Notre responsabilité est collective de ne pas utiliser les services qui ne correspondent pas à une logique d'interopérabilité. De toutes façons, loi ou pas, c'est déjà mal parti vu que la majeure partie des utilisateurs se contrefout de l'interopérabilité¹… sinon ce serait déjà fait, auquel cas il n'y aurait pas besoin de loi.
¹ Y a qu'à demander autour de nous. Qui parmi eux sait même ce qu'est l'interopérabilité?
# Ça me laisse perplexe...
Posté par FantastIX . En réponse à la dépêche Zoom sur trois projets émergents portés par Mozilla : Fluent, Bugbug et BinaryAST. Évalué à -4.
Une IA pour corriger les bugs dans des programmes… Il y a quelque chose qui me… comment dire… («ça vous chatouille? ou ça vous grattouille?»)
C'est moi ou on va un peu loin, là? Pourquoi pas inventer une IA qui agirait génétiquement sur les humains pour qu'ils soient capables d'écrire des programmes sans bug? Ah ouais, mais alors on n'aurait plus besoin des IA. C'est con. Y a plus qu'à faire écrire des programmes par des IA. Ah ouais, ça se fait déjà…
Bon, ça va -->[]
# Internet ou la révolution du partage
Posté par FantastIX . En réponse à la dépêche Revue de presse de l’April pour la semaine 19 de l’année 2019. Évalué à 4.
Le documentaire est disponible sur Youtube.
[^] # Re: Bulshit !
Posté par FantastIX . En réponse à la dépêche Revue de presse de l’April pour la semaine 19 de l’année 2019. Évalué à 4.
C'est marrant, quand j'ai lu «[…] du stade d’idée à celui de business model […]» j'ai, juste l'espace d'un instant, cru lire «du stade d’idée à celui de business bordel» …
[^] # Re: Soit j'ai rien compris soit...
Posté par FantastIX . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à -1.
Je ne comprends pas cette obsession autour de git revert et de l'idée d'annuler des patch. J'ai répondu avec une commande du style:
git diff X Y | patch
que personne n'a commenté, non content de ça et qui s'est faite moinsser sans la moindre explication. J'aimerais comprendre, c'est tout.
Ré-écrire l'historique, quelle qu'en soit la raison, dans un projet quel qu'il soit est en effet une très mauvaise idée et le commentaire de barmic explique pourquoi. Alors, je repose ma question, autrement: est-ce qu'il y a quelque chose de dérangeant dans ma suggestion? Et, si oui, pourquoi?
[^] # Re: Soit j'ai rien compris soit...
Posté par FantastIX . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à -1.
Ok. Alors dans ce cas, je ne suis pas d'accord sur la conclusion que tu fais de mes propos. J'ai tenu cette liste comme exemples de raisons pour lesquelles on ne doit pas juger un produit sur le simple fait de devoir faire des recherches, ce qui s'appelle une déduction hâtive. Et j'ajouterais aussi: «même pour des cas triviaux». La mémoire, si on ne tient compte que de ça, ben ça flanche. Que tu considères que ces recherches soient "normales" ou non, est sans rapport avec mon propos.
Le cas des médicaments que tu soulèves est un cas particulier du mien et pour lequel je ne partage pas non plus ton point de vue (à savoir que c'est normal de rechercher dans ce cas là). Que mon exemple te paraisse bancal ne contredit en rien qu'il n'est pas bon de faire des déductions hâtives.
Alors ça tombe bien, je lui ai répondu avec un exemple qui tient en une seule commande. J'espère que tu as vu ma réponse. Dis-moi ce que tu en penses.
Hmmm… tu me donne une charge que je ne suis pas forcé d'accepter. Mais bon, j'arrête de pinailler.
[^] # Re: Soit j'ai rien compris soit...
Posté par FantastIX . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 3. Dernière modification le 05 mai 2019 à 11:43.
Ta question est pertinente et, si c'est à moi que tu poses cette question, je répète, je n'ai pas la solution, n'étant pas non plus un fin connaisseur de Git. Je ne pourrai être certain d'y répondre proprement que lorsque j'aurai du temps à y consacrer.
Ceci dit, on est peut-être en train de chercher midi à quatorze heures. En y réfléchissant quelques secondes de plus, si je te suggères de demander à Git de te renvoyer un patch complet correspondant à la liste des modifications de la branche A (genre git diff ), puis que tu appliques ce patch à "l'envers" (commande patch -r), as-tu ta réponse?
En somme:
Voire mieux:
Ou encore:
L'avantage est que 1) tu n'as pas à annuler quoi que ce soit (c'est quoi "annuler", d'ailleurs?), 2) il n'est pas nécessaire de ré-écrire l'historique (puisque c'est "mal") si le dépôt public a été modifié et 3) tous les dépôts restent cohérents. Au final, je vois ladite annulation comme une opération de plus.
Et on fait ça avec Git en une seule commande et une seule ligne. À condition que j'aie bien compris ta question, cela va de soi. Je n'ai pas parlé de l'argument "--dry-run" avant d'appliquer un correctif mais prudence oblige, bien entendu.
Est-ce que cette proposition répond à ta question?
[^] # Re: Soit j'ai rien compris soit...
Posté par FantastIX . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à -1.
Je ne saisis pas. Peux-tu m'expliquer?
[^] # Re: Soit j'ai rien compris soit...
Posté par FantastIX . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
J'aime bien ça:
(accentuation par moi)
[^] # Re: Soit j'ai rien compris soit...
Posté par FantastIX . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à -4.
Je n'ai pas encore eu à traiter le cas que tu soulèves. Je dois aussi avouer que c'est pas tous les jours que j'élimine des branches ;-). Je ne pourrai donc que répondre de manière intuitive, sur base des commandes que je connais.
Je dirais donc, sur base de ces préliminaires, de supprimer les commits de la branche A. Si je ne m'abuse, supprimer une branche revient à supprimer ses commits. Maintenant, vu que la branche a été fusionnée, je n'ai aucune idée de ce que ça donnerait.
En fait, j'en sais foutre rien :-D. En général, je cherche sur internet lorsque le cas se présente. Et ça ne me dérange pas le moins du monde.
Permets-moi de ne pas partager ce point de vue.
Est-ce que ça veut dire que Python, C, C++, Git, Linux, bash, les médocs, la signalisation routière (ou quoi ou qu'est-ce) ont tous un problème? Ou bien, principe de parcimonie aidant, que je n'ai juste pas une bonne mémoire? Ou bien que je n'utilise pas assez souvent ces ustensiles pour qu'ils me restent en mémoire? Ou que ces outils sont trop complexes pour moi parce qu'ils contiennent plus de variantes ou d'options que ce que j'arrive à retenir? Ou bien parce qu'étant une grosse feignasse, vu que je sais où me documenter, je ne fais pas/plus le moindre effort pour m'en souvenir?
Laquelle de ces explications est la bonne? Peut-être qu'elles le sont toutes?
Tu vois, je ne suis pas aussi catégorique pour juger de ce qu'un outil est bien ou mal fichu. Tout ça relève de l'opinion personnelle dans la plupart des cas. Il y a plus d'une explication pertinente dans pas mal de situations. Le tout est de trouver la plus pertinente. Ça n'est pas toujours facile. Qualifier l'outil est plutôt tentant mais en le faisant, on risque de passer à côté de points bien plus importants, peut-être à côté de l'essentiel.
Git est complexe. Ça, c'est vrai. Trop complexe? C'est bien possible. Mais quand on observe autour de nous, est-ce que "les choses" n'ont pas tendance à se complexifier au point de ne plus pouvoir être maîtrisables par un seul humain? Ne serait-ce pas un signe des temps?
J'en sais rien en fait, je pose juste une question. Enfin, quelque part, si, je me doute. Je me rends compte, notamment, que l'informatique devient de plus en plus complexe et compliquée. Et je pense (c'est mon opinion) que c'est parce que de plus en plus de développeurs n'arrivent pas/plus à apporter des solutions simples à des problèmes simples. Dans beaucoup de cas, j'accepte cette complexité et je fais avec. Dans d'autres cas, je la refuse et je fais tout moi-même. Et parfois, aussi, je baisse les bras et je tourne la page.
Mais bon, je digresse, c'était pas le sujet principal, désolé.
Git a près (plus?) de quatorze ans. Pijul, si j'ai bien lu, a trois ans. Au train où vont les choses, il vaudrait mieux repasser dans une dizaine d'années; on verra bien comment/si l'un et l'autre auront évolués, si notre concept de "simplicité" (et le reste) n'a pas lui non plus évolué…
N.B.: je fais volontairement une différence entre complexe (association d'un grand nombre de choses simples) et compliqué (qu'on a du mal à comprendre, par exemple parce que mal foutu, pas ou peu intuitif, contraire au bon sens…) Donc quelque chose de complexe peut être facile à comprendre, par exemple parce que bien détaillé ou documenté pour chacun de ses sous-ensembles.
[^] # Re: Business is business
Posté par FantastIX . En réponse à la dépêche SEO, SEO, SEO, SEO et aussi le SEO. Évalué à 2.
Moi, mon karma, l'est dans le comma. Sans doute à cause de mes Attaques répétées sur Linuxfr…
-->[]
[^] # Re: Soit j'ai rien compris soit...
Posté par FantastIX . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à -3. Dernière modification le 04 mai 2019 à 08:58.
Merci!
Exprimé comme ça, en effet, ça m'éclaire un peu plus sur ce que l'auteur a voulu exprimer concernant ce qui est intuitif ou pas.
… sauf que ce n'est pas exactement ce que j'ai dit. Je n'ai pas la prétention de faire les choses bien, j'affirme juste m'inspirer de ceux qui, eux, font bien. Après, je fais de mon mieux et je m'applique.
Ensuite, j'affirme en effet ne pas avoir de problème avec Git et j'explique (en gros) pourquoi. Le reste, «donc si on fait bien les choses bien […]» est une interprétation d'un sous-entendu que je n'ai jamais eu l'intention d'exprimer… et que je n'ai pas exprimé non plus!
Ma litanie est centrée sur une généralisation de la part de l'auteur sur l'inexistence de cette fameuse perception intuitive, ce que je considère excessif (permets-moi un peu de poésie). Et pour réfuter cette affirmation, j'ai tenu le raisonnement suivant, même si je ne l'ai pas détaillé.
La probabilité qu'un développeur lambda rencontre les termes "snapshot", "commit" et "patch" est relativement élevée. On trouve le terme "snapshot" dans le jargon de la virtualisation et de la sauvegarde, les backups. Le terme "commit" se rencontre dans celui des bases de données, notamment. Le "patch" est un terme commun, notamment pour toute personne qui se sert de Linux ayant un jour voulu remonter un bug ou soumettre un correctif (mais pas que).
La probabilité que ces trois termes soient rencontrés par un développeur est relativement élevée. En effet, il n'est pas rare qu'un développeur, dans sa carrière, manipule des bases de données, des machines virtuelles et fasse aussi des backups — c'est à espérer, d'ailleurs! Donc si ces termes sont rencontrés et qu'ils sont bien compris, il ne devrait pas y avoir de confusion.
C'est ça, le raisonnement que j'ai tenu et c'est sur cette seule affirmation (à propos de la perception intuitive) que j'argumentais. Je ne remets en question son produit en aucun cas, bien évidemment.
L'auteur aurait déclaré: «il existe pas mal de monde qui confond patch et commit avec Git, voici pourquoi: …», je n'aurais probablement pas réagi. Peut-être même pas du tout.
De fait. Je n'ai pas suivi l'affaire depuis mon premier commentaire.
On est bien d'accord :-) .
[^] # Re: Soit j'ai rien compris soit...
Posté par FantastIX . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à -1.
Et merde…
[^] # Re: Soit j'ai rien compris soit...
Posté par FantastIX . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à -2.
Merci pour tes explications, dont je retiendrai en essence ceci:
C'est effectivement ce qui répond à la question que je n'ai pas posée de manière explicite. J'en déduis donc que tu possèdes de nombreux retours d'utilisateurs pour en être arrivé à cette conclusion. C'eût été intéressant d'en connaître les proportions, ceci dit. Ce n'est pas une critique, je manifeste juste ma curiosité.
J'aimerais revenir sur certains de tes propos. Tout d'abord:
J'en ai exactement la même compréhension.
Ensuite tu reprends et détailles les différents points que j'ai énumérés. Merci pour cet effort d'avoir détaillé l'expérience des autres.
Cependant je n'ai abordé ces points que pour détailler ce qui comptait pour moi… puisque mon commentaire concluait que je n'ai pas encore eu de raison de passer à autre chose [que Git]. Je ne faisais donc que détailler mon expérience personnelle et en quoi je n'ai pas (encore) eu de raison de changer, puisque Git 1) n'a jamais été pour moi source de la confusion dont tu parles et 2) m'apporte une réponse [au moins] satisfaisante à tous les besoins que j'ai énumérés — ce dernier point était implicite, il n'était pas exprimé, c'est vrai.
Mon commentaire partait d'ailleurs de la confusion entre «commit» et «patch», d'accord? C'est sur cette base, agrémentée de plusieurs autres points, que j'ai argumenté pour arriver à la conclusion.
J'ai appris à me démerder et je prends toujours le temps d'apprendre à bien faire les choses dès le début auprès de ceux qui ont l'expérience. J'ai toujours été clair là dessus avec mes employeurs. J'investis ce temps pour mes projets personnels, ce qui me permet d'appliquer au boulot ce que j'apprends.
Je suis conscient d'être probablement un privilégié. Mais à partir du moment où je peux me le permettre…
Pour le reste, j'aimerais aborder des points qui ont tendance à m'irriter un tantinet:
Qu'est-ce qui te fait croire que j'imagine que «mes interlocuteurs» délirent?
Et par «tes interlocuteurs», c'est de toi que tu parles?
Où exactement et en quoi ai-je réduit ton produit à une simple question de vocabulaire?
Puisque tu abordes ce sujet, dois-je en déduire que tu insinues que je délire?
Ça a le style, l'air et les termes d'une attaque personnelle. Tu peux développer, STP?
Tout message est laissé à l'interprétation de celui qui le reçoit et je ne peux être tenu pour responsable de l'interprétation que quiconque fait de mes propos, surtout sur base du texte seul et sans l’intonation ni l'expression de mon visage. Si tu t'es senti blessé par ce que j'ai raconté, ce n'était pas mon intention; si tel est le cas, j'en suis vraiment navré.
Lorsque j'ai mentionné le mot «vocabulaire», je parlais de la discussion, pas de ton produit. Dans tous les cas, un outil vient avec son vocabulaire et son formalisme, qu'il convient d'apprendre et de maîtriser, que l'outil soit informatique ou non. Tu ne partages pas cette analyse?
Si le vocabulaire et le fonctionnement de Git son mal compris, c'est sans doute là qu'il faut agir — et je ne pars pas du principe que tu ne l'as pas fait. Dans ces cas-là, plusieurs possibilités existent: 1) améliorer la documentation et la compréhension des utilisateurs, 2) améliorer le produit pour qu'il soit mieux compris, 3) changer de produit, 4) en créer un nouveau.
Soit dit en passant, créer un nouveau produit ou en changer parce que le premier n'est pas compris par ses utilisateurs ne résoudra pas ce problème en particulier, n'est-ce pas?
Je n'ai pas mentionné que ça! Pourquoi t'attarder là-dessus uniquement, alors que j'ai clairement indiqué que je me réfère au manuel ET à ce que je trouve sur internet quand ce dernier ne m'aide pas? À part pour faire un appel au ridicule, je ne vois pas l'intérêt d'un tel commentaire.
J'aurais exprimé ça où, exactement?
Bon, pour terminer sur une note positive:
Je n'en ai effectivement jamais douté.
[^] # Re: Soit j'ai rien compris soit...
Posté par FantastIX . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
Ce que tu fais là s'appelle un procès d'intention. Soyons clairs, d'abord tu n'es pas dans ma tête; tu ne peux donc savoir ce que je cherche — ce que j'ai écrit n'en constitue pas l'expression intégrale et tu disposes de trop peu d'information pour te faire une idée rigoureuse de ce que j'ai en tête et de ce que je cherche exactement.
Ensuite, si j'ai proféré cette affirmation, c'est tout simplement pour exprimer que je ne comprends pas celle de l'auteur. Après, que tu te méprennes sur mes intentions, ma foi, je n'ai pas demandé explicitement que l'auteur éclaircisse ses propos, c'est exact. S'il le fait (et c'est d'ailleurs le cas dans son commentaire plus bas), alors tant mieux et merci à lui.
Finalement tu m'expliques ce qu'est un commit pour Git (ce que je sais déjà) et ce qu'est un patch au sens de Pijul. Merci bien, mais ça n'éclaire pas ma lanterne en quoi l'un peut être plus (ou moins) intuitif que l'autre.
Un commit et un patch sont deux choses totalement distinctes, que l'on ne peut comparer — un cliché (ou un commit) est un moyen pour Git d'arriver au résultat souhaité, un patch, le second est donc le résultat du premier. Donc dire que l'un est plus intuitif que l'autre, ça n'a pas de sens pour moi.
Si je suis arrivé à cette conclusion, c'est donc qu'il n'y a aucune ambiguïté en ce qui me concerne — je répète: je parle pour moi, je ne prends pas mon cas pour un généralité. Voilà pourquoi j'ai affirmé ne pas comprendre ce qui amenait l'auteur à dire ça.
[^] # Re: Soit j'ai rien compris soit...
Posté par FantastIX . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 3.
Euh… pardon? Je ne comprends pas cette affirmation. C'est comme affirmer "un dessin est plus intuitif qu'un crayon". C'est du moins comme ça que je perçois cette phrase.
Un commit, c'est une transaction, exactement comme pour une base de données. Un snapshot, c'est comme pour une VM: un cliché, un instantané. Un patch, c'est un correctif. Les trois sont intuitifs, quand on a déjà des références, ce qui ne doit pas être impossible, surtout pour un développeur. Ça ne signifie pas nécessairement que ces termes sont interchangeables mais que leur compréhension est assez aisée.
Sinon, je pense que cette discussion focalise un peu trop sur le vocabulaire par rapport aux fonctionnalités. Qu'on appelle ce "truc" un "patch", un "commit", un "snapshot", quelle importance? Ce que demande un développeur, AMHA, c'est que l'outil fonctionne, qu'il lui donne satisfaction et lui permette de faire ce qu'il désire sans se prendre le chou. Maintenant, que ce soit à travers des "patches", des "commits", des "snapshots", des "branches", des "rebase"… tout ça c'est juste du formalisme à se farcir. Pour tirer le meilleur parti d'un outil, il faut maîtriser son utilisation — oui, le vocabulaire en fait partie.
En ce qui concerne un outil de gestion de code source — je parle pour moi — tout ce qui m'intéresse, c'est, par exemple:
Avec ça, si je ne connais pas la commande, je sais que je peux la trouver sur internet. En fait je me moque pas mal que la commande ne soit pas intuitive car je n'ai pas besoin de me souvenir de toutes les commandes disponibles. J'ai les pages du manuel et, si vraiment je suis bouché, je trouve sur StackOverflow. Ou ailleurs.
Perso, je n'ai rien vu (rien cherché non plus, j'avoue), jusqu'à présent, qui me détourne de Git. Et il y a beaucoup de cerises sur le git-eau…
A priori Pijul ne donne pas de motif suffisant à changer par rapport à Git. Je pense que c'est l'un des points abordés par Jean Parpaillon dans ses commentaires.
Ceci dit, c'est très bien que des outils comme ça naissent aussi. Après tout, c'est aussi un des [nombreux] aspects du logiciel libre. Avoir plus d'un point de vue, éclairé ou pas, que chacun puisse faire son choix, en toute liberté, c'est bien. Après, c'est la nature [humaine] qui décide ;-) …
# Intéressant!
Posté par FantastIX . En réponse à la dépêche La norme française de dispositions de clavier a été publiée. Évalué à 3. Dernière modification le 09 avril 2019 à 15:31.
La nouvelle disposition AZERTY ressemble pour beaucoup à la disposition «Français (Macintosh)», que j'utilise principalement. Ce sont entre autres les caractères æ, œ, \, |, ~ qui ont des positions similaires voire identiques.
[^] # Re: Chaîne d'utilité publique
Posté par FantastIX . En réponse à la dépêche « Hygiène mentale » : une chaîne de vidéos sur l’esprit critique, sous licence de libre diffusion. Évalué à 6.
+2!
Je prends aussi de plus en plus de plaisir avec les chaînes françaises qui dépolluent l'esprit comme Astronogeek, Defakator, Florence Porcel, La Tronche en Biais, Les Revues du Monde, Science étonnante,
Science4All, …
Ce qui les rassemble, c'est le temps que ces personnes investissent pour collecter l'information à la source, la compiler et la résumer pour tous. Chacune d'elles mériterait bien un article. À
consommerconsulter sans modération…![^] # Re: En tout cas la communauté DLFP est super accueillante…
Posté par FantastIX . En réponse à la dépêche « Hygiène mentale » : une chaîne de vidéos sur l’esprit critique, sous licence de libre diffusion. Évalué à 0.
Le radicalisme… fustigé par un radicaliste? Noon, ça existe pas ici, quand même?
-->[]
[^] # Re: qui croire ?
Posté par FantastIX . En réponse à la dépêche Firefox 66 sur la route !. Évalué à 3.
Ok, je me corrige: l'EFF ne demande pas explicitement de supprimer les certif's QuoVadis mais explicitement ceux de DarkMatter. C'est l'article de Korben qui est foireux! (ou pute-à-clics, de toutes façons c'est pareil *soupirs*)