Journal Microsoft passe à git

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
23
31
jan.
2013

Pour ses outils de développement, microsoft va promouvoir git avec notamment un support natif dans visual studio et le plugin pour faire la migration de tfs vers git.

On peut espérer un meilleur support de git dans windows, même si cela s'est bien améliorer depuis les premières versions.

Source : http://www.networkworld.com/news/2013/013013-microsoft-embraces-open-source-git-for-266280.html

  • # Je profite de ce troll

    Posté par  . Évalué à 2.

    Je sais que trolldi est demain, mais question : est-ce quelqu'un connais aussi bien Mercurial que Git et préfère Mercurial ?

    J'ai essayé plusieurs fois d'utiliser Mercurial pour mes projets perso, mais le truc ne sait rien faire de base, il faut avoir recours à des extensions : pour éditer l'historique (git rebase -i), faire des commit partiels (git add -p). Et il y a des concepts que je n'arrive pas à retrouver (le concept de dépôt distant, git remote)

    Un fanboy de Mercurial pourrait-il m'expliquer ce qu'il aime dans Mercurial et pourquoi ça roxxe du poney ?

    Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

    • [^] # Argument massue

      Posté par  (site web personnel) . Évalué à 0.

      Mercurial, c'est immutable, et donc c'est Bien®

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Argument massue

        Posté par  . Évalué à 3.

        Argument valable aussi pour Fossil !
        (qui de surcroît est beaucoup plus simple, multi plate-forme, et possède une ui web et un wiki intégrés, et tout l'historique est stocké dans une base sqlite…)

        • [^] # Re: Argument massue

          Posté par  (site web personnel) . Évalué à 2.

          (qui de surcroît est beaucoup plus simple, multi plate-forme, et possède une ui web et un wiki intégrés, et tout l'historique est stocké dans une base sqlite…)

          Je comprends pas, tu commences ta phrase par des avantages et tu finis par des inconvénients. Je suis désolé mais l'ui et le wiki intégré, ce n'est pas quelque chose que je recherche. Je préfère des outils par besoins et capables de s'intégrer les uns aux autres. Et la façon dont l'historique est stocké, je m'en tape royalement du moment où je peux le récupérer comme je veux et que ça marche.

          • [^] # Re: Argument massue

            Posté par  (site web personnel) . Évalué à 6.

            Fossil est un dvcs particulier : son binaire fait autour de 800k compilé, ne nécessite aucune dépendance, import/export git, intègre le bug tracker, le wiki et l'historique via une interface web dont le serveur est intégré ou en CGI.

            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

            • [^] # Re: Argument massue

              Posté par  . Évalué à 1.

              Ne serait-il donc pas plus logique de le comparer à git/mercurial/bzr/darcs associé à Trac/Redmine/Gitorius/whatever ou même à une cafetière plutôt qu'à un outil ne faisant que DVCS ?

            • [^] # Re: Argument massue

              Posté par  . Évalué à 3.

              Fossil est sympa, surtout couplé à Fuel.
              Mais il est encore en maturation.
              Pour l'avoir utilisé intensément ces derniers temps (en mono utilisateur), il y a des plantages inexpliqués au commit et encore plus au sync entre deux repo.
              J'ai été obligé d'éditer la base sqlite pour m'en sortir et de recréer le repo remote complétement.
              Bref, j'adore ce que fait l'auteur de sqlite, mais je ne conseille pas encore fossil pour un projet pro.

              • [^] # Re: Argument massue

                Posté par  (site web personnel) . Évalué à 3.

                Je trouve ça étrange, je l'utilise depuis longtemps sans le moindre problème. Ne serait-ce pas plutôt Fuel qui pose problème ?

                "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

              • [^] # Re: Argument massue

                Posté par  (site web personnel) . Évalué à 3.

                Je l'utilise intensément* depuis bientôt deux ans et je ne l'ai jamais vu planter.

                *: en mixant des versions différentes sur des os/machines diverses, avec de gros binaires, des CTRL-C au milieu d'une synchro ou d'un commit, bref de quoi bien tout pourrir!

                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Argument massue

            Posté par  . Évalué à 3. Dernière modification le 01 février 2013 à 11:38.

            Personne ne dit que Fossil est mieux dans tous les cas (cf ta phrase "ce n'est pas quelque chose que je recherche" : eh bien soit ! Mais je ne vois pas en quoi le serveur+wiki intégrés sont pour autant un inconvénient ! Personnellement, je trouve cet aspect autonome (sans dépendances) extrêmement commode dans de nombreuses situations et ça facilite sa démocratisation). L'utilisation de sqlite n'est pas un vrai argument, mais c'est juste pour dire que c'est simple à backuper et/ou à interroger avec des outils externes, etc.)

    • [^] # Re: Je detourne de ce troll

      Posté par  . Évalué à 1.

      mais le truc ne sait rien faire de base

      Ca marche aussi pour bzr

      il faut avoir recours à des extensions

      Ca marche aussi pour bzr. Au passage la moitier des extensions sont pourries ou mortes

      pour éditer l'historique (git rebase -i)

      Ca marche pas pour bzr. Y'a bien un plugin rewrite mais le -i faut pas rêver. Un DCVS où on peut bosser efficacement avec des branches locales n'y pensez pas mon bon monsieur

      faire des commit partiels (git add -p)

      Non plus.

      Et il y a des concepts que je n'arrive pas à retrouver

      Ca marche aussi. Par contre ils arrivent à inventer des concepts moisis. C'est "beau" mais inutilisable en pratique.

      Un fanboy de Mercurial pourrait-il m'expliquer ce qu'il aime dans Mercurial et pourquoi ça roxxe du poney ?

      Idem…

      PS: Dis moi mercurial c'est aussi rapidelent et bien outillé que bzr ?

    • [^] # Re: Je profite de ce troll

      Posté par  . Évalué à 1.

      Je ne peux être objectif car j'ai fait que très peu de Mercurial il y a longtemps et je n'avais pas fait de git, mais ce que je perçois c'est que le seul avantage de Mercurial par rapport à git c'est qu'il est plus facile à apprendre/prendre en main (tout en étant un DVCS et donc apporte pas mal de chose par rapport à un VCS).

      Pour le reste, git est bien plus performant, souple, outillé, utilisé,…

      • [^] # Re: Je profite de ce troll

        Posté par  (site web personnel) . Évalué à 8.

        Deux gros reproches qu'on peut faire à git:

        • le support Windows reste extrêmement bancal. Notamment la conversions des sauts de lignes (mais ça a peut-être évolué depuis la dernière fois que je me suis cassé les dents dessus)
        • les outils graphiques sont quand même à la ramasse, surtout pour Windows. J'ai testé GitHub Windows, Git GUI, Git Extensions et ça reste bof bof bof.

        A côté de ça, côté mercurial:

        • fonctionnement 100% identique sous Linux et sous Windows. On a pas l'impression d'être des rejetés
        • TortoiseHG rocks, et de la même façon sous Linux et Windows.

        • [^] # Re: Je profite de ce troll

          Posté par  . Évalué à 2.

          Deux gros reproches qu'on peut faire à git:

          Et surtout les mainteneurs sont des douchebags, port Windows comme client officiel (se comporter comme Linus quand on n'est pas Linus et que le projet n'est pas le noyau, bizarrement ca ne marche pas vraiment pour attirer les contributeurs)

          Mais c'est en train de s'arranger, puisque tout le monde bosse sur des libs pour zapper le projet officiel, le portage de daube et l'API de merde du client officiel.

          les outils graphiques sont quand même à la ramasse, surtout pour Windows.

          Tu as essaye SmartGit?

          • [^] # Re: Je profite de ce troll

            Posté par  (site web personnel) . Évalué à 1.

            Et surtout les mainteneurs sont des douchebags, port Windows comme client officiel (se comporter comme Linus quand on n'est pas Linus et que le projet n'est pas le noyau, bizarrement ca ne marche pas vraiment pour attirer les contributeurs)

            Tu pense à qui en particulier ? Des exemples de comportement « a la Linus » ?

        • [^] # Re: Je profite de ce troll

          Posté par  . Évalué à 1.

          Tu n'as pas essayé TortoiseGit ?

    • [^] # Re: Je profite de ce troll

      Posté par  . Évalué à 7.

      Je sais que trolldi est demain, mais question : est-ce quelqu'un connais aussi bien Mercurial que Git et préfère Mercurial ?

      J'en connais quelque uns.

      J'ai essayé plusieurs fois d'utiliser Mercurial pour mes projets perso, mais le truc ne sait rien faire de base

      Linus avait, dés le départ une vision assez claire de ce qu'il souhaitait (faut dire qu'avec plusieurs années de BitKeeper et la gestion d'un gros projet derrière lui, ca aide bien).

      Un fanboy de Mercurial pourrait-il m'expliquer ce qu'il aime dans Mercurial et pourquoi ça roxxe du poney ?

      2 arguments récurrents :
      - le frontend est bien plus simple
      - la courbe d'apprentissage est faible quand on vient de SVN.

      Autant Hg peut s'utiliser comme un SVN décentralisé (en gros, je ne change pas mes habitudes, je rajoute juste un pull / push), autant Git demande à complètement revoir ses connaissances et ses habitudes si on ne veut pas être perdu. C'est comme passer d'une voiture à une moto, on peut pas juste modifier 2/3 habitudes. C'est seulement à cette condition qu'on perçoit la puissance et la cohérence de Git (là ou Hg commence à sérieusement cumuler les couches).

    • [^] # Re: Je profite de ce troll

      Posté par  (site web personnel) . Évalué à 9.

      Je ne connais pas aussi bien Mercurial que Git, mais il y a quand des trucs bien dans Mercurial qui ne sont pas dans Git, par exemple :

      http://mercurial.selenic.com/wiki/Phases
      http://www.selenic.com/mercurial/hg.1.html#specifying-revision-sets

    • [^] # Re: Je profite de ce troll

      Posté par  (site web personnel) . Évalué à 8. Dernière modification le 31 janvier 2013 à 19:00.

      Je préfère mercurial parce que j'ai jamais vraiment pris la peine d'utiliser git, et que je vois pas pourquoi je m’embêterais à apprendre un truc aussi compliqué au premier abord (bon après, je code peu, et souvent seul).

      J'ai utilisé svn, et passer à mercurial ne demande quasiment aucun effort (et ça c'est parfait) tout en ayant toute la flexibilité qui m'ai(s/t*) nécessaire pour mes petits projets. (Et je pense que cet argument est l'argument numéro 1 pour pas mal de monde)

      Pour le git rebase, il parait que c'est mal :p (mais je crois que c'est possible, j'en sais rien)
      Pour le commit partiel, il me semble qu'il suffit d'indiquer juste les fichiers que tu veux commiter, tout simplement.
      Et le concept de dépôts distant, je sais pas trop ce que sait, donc je ne dirais rien.

      Enfin bref quand la majorité des commandes que tu utilises c'est : commit, add, log, pull, push, revert… je vois pas pourquoi tu devrais t'embêter à apprendre quelque chose d'autre tant que tu n'en as pas l'utilité.

      Et sinon d'autres argument en vrac:
      - mercurial c'est du python, donc c'est forcément génial :D
      - le nom est mieux, pour un chimiste en tout cas
      - faut bien se distinguer de temps en temps
      - à bas github, vive bitbucket (https://bitbucket.org/)
      - intégration forte facilement possible dans des projets python
      - …

      • là comme ça j'ai un doute, je vous laisse le choix

      • [^] # Re: Je profite de ce troll

        Posté par  (site web personnel) . Évalué à 10.

        la flexibilité qui m'ai(s/t*) nécessaire

        c'est pas m'est?

      • [^] # Re: Je profite de ce troll

        Posté par  . Évalué à 4.

        Je préfère mercurial parce que j'ai jamais vraiment pris la peine d'utiliser git, et que je vois pas pourquoi je m’embêterais à apprendre un truc aussi compliqué au premier abord

        idem : j'ai utilisé (et j'utilise encore un peu, hélas) SVN, et c'est vraiment aisé de passer à mercurial ensuite, et ça me convient parfaitement pour mes besoins en la matière.

        « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

      • [^] # Re: Je profite de ce troll

        Posté par  (site web personnel) . Évalué à 6.

        Pour le commit partiel, il me semble qu'il suffit d'indiquer juste les fichiers que tu veux commiter, tout simplement.

        Avec git, un commit partiel, ça peut être sur seulement certaines modifications d'un fichier…

        • [^] # Re: Je profite de ce troll

          Posté par  (site web personnel) . Évalué à 5.

          Avec Mercurial aussi ( http://mercurial.selenic.com/wiki/RecordExtension ).

          La différence, c'est qu'avec Git, l'état du futur commit partiel (l'index) est enregistré sur le disque, donc on peut s'y prendre en plusieurs fois ("git add -p", je commence, ah tiens non, je re-code un truc, "git add -p" pour continuer, "git reset -p" pour en enlever des bouts, …).

          Si j'ai bien compris, on peut faire ce genre de choses avec mq côté mercurial.

      • [^] # Re: Je profite de ce troll

        Posté par  (site web personnel) . Évalué à 2.

        On peut faire du git sur bitbucket. Site qui a d'ailleurs joyeusement repompé Github lors de leur dernier gros changement d'UI :D.

      • [^] # Re: Je profite de ce troll

        Posté par  (site web personnel) . Évalué à 6.

        Idem aussi.

        J'utilise Mercurial, car je le trouve plus simple que Git. Et avec Mercurial vient Rebase, Mq ! (Un vrai plus quand on vient de SVN, et le Graal quand on vient de CVS).

        De plus je préfère justement la gestion des branches dans Mercurial (par rapport à la gestion dans Git). Question de gout.

      • [^] # Re: Je profite de ce troll

        Posté par  . Évalué à 1.

        Pour le commit partiel, il me semble qu'il suffit d'indiquer juste les fichiers que tu veux commiter, tout simplement.

        Non, les commits partiels c'est quand tu commit que certaines lignes dans un fichier.

        L'extension record le permet, mais encore une fois, c'est une extension.

        Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

    • [^] # Re: Je profite de ce troll

      Posté par  (site web personnel) . Évalué à 10.

      est-ce quelqu'un connais aussi bien Mercurial que Git et préfère Mercurial ?

      S'il n'en existe pas ou peu, j'aurais une explication que j'applique aussi à certaines théories mathématiques : une fois que tu t'es carré l'apprentissage d'un truc aussi compliqué, tu te sens obligé de l'utiliser partout, et Stockholm aidant, tu finis par l'aimer.

      • [^] # Re: Je profite de ce troll

        Posté par  . Évalué à 10.

        comme vi

        • [^] # Re: Je profite de ce troll

          Posté par  (site web personnel) . Évalué à 3.

          pas d'accord, c'est plutôt comme emacs
          vi est beau, vi est bon, ya de gros morceaux dedans et ça lave plus blanc

          c'est dredi !
          Chris

          • [^] # Re: Je profite de ce troll

            Posté par  . Évalué à 0.

            Emacs vit avec son temps, il a une interface graphique pour les gens qui n'aiment pas les raccourcis claviers. :p

            Emacs le fait depuis 30 ans.

            • [^] # Re: Je profite de ce troll

              Posté par  (site web personnel) . Évalué à 1.

              Si vraiment tu veux aller sur ce terrain, il y a aussi des interfaces graphiques pour vim, elles sont juste un peu plus modernes. (et plus sérieusement, ça peut être pas mal pour débuter, ça évite le côté frustrant du début)

    • [^] # Re: Je profite de ce troll

      Posté par  (site web personnel) . Évalué à 10.

      Alors… dans une précédente boite je m'étais justement occupé de la migration de notre svn. J'ai donc testé git, mercurial et bzr. Avant d'aller plus loin, on est passé à mercurial, je l'ai utilisé pendant en gros deux ans. J'utilisais git avant, pendant, et après, y compris pour des projets pro.

      Pour commencer, bzr a des bons côtés je trouve, il est plutôt souple sur sur fonctionnement. Mais il a beaucoup de défauts et rien que sa lenteur fait que je n'ai jamais pu le blairer ! Pourtant j'ai vraiment essayé

      Maintenant, git et mercurial. J'ai apprécié mercurial, il fonctionne plutôt bien. C'est déroutant que certaines commandes soient inversées lorsqu'on fait du mercurial et du git, mais bon c'est pas grand chose.
      Mercurial fonctionne bien, mais je suis d'accord pour le côté extensions, c'est nul. Idem pour l'absence d'un équivalent correct aux submodules.

      Pendant longtemps j'ai taillé mercurial pour sa gestion des branches. Ensuite j'ai compris comment ça fonctionnait et j'ai apprécié. Ensuite j'ai taillé git mercurial pour sa gestion des branches.

      Je m'explique : dans mercurial la branche n'est qu'une méta donnée d'un commit. Pour qu'une branche existe il faut au moins un commit. Dans git une branche est un pointeur vers un commit. Pas besoin de commit dans la branche pour qu'elle existe, plus simple pour créer plusieurs branches depuis un même état.

      Au final cela induit une vrai différence d'usage (et c'est là où je trouve qu'il y a réellement un point commun, dans l'usage, avec svn, contrairement à ces histoires de frontend qui sont un peu ridicules).
      Dans git, on va brancher d'abord (beaucoup de branches nommées juste pour faire quelques commits, topic branches, court terme) pour préparer le boulot. Genre, je vais bosser sur si, sur ça, sur cet autre point, allez hop je crée 3 branches.
      Dans mercurial, on va brancher plutôt au besoin (si on ne parle pas de branches long terme). On va toujours bosser dans default. Si j'ai besoin de corriger un commit, je remonte l'historique pour me placer dessus, et je commit directement. Je viens de créer un head, pas besoin de faire une branche. Et hop, je merge. Si j'ai plusieurs choses à faire, pareil. Je me met sur default et je bosse. Lorsque je veux passer sur une autre tâche, je reviens à mon état initial et je bosse. On est plus dans du "branch as needed" et on utilise beaucoup plus les branches anonymes.

      Au final, je préfère le fonctionnement de git, mais parfois j'aime bien celui de mercurial tout de même.

      Quelques liens (ça vient du même site mais ça c'est pas grave c'est plutôt de qualité) :

      Ha oui, et côté mercurial j'ai très souvent utilisé mq avec pas mal de plaisir. Sous git il m'arrive souvent d'utiliser stgit. Et je vous encourage vraiment à les utiliser, surtout si vous vous souciez de votre historique.

      Voilà, ça répond pas totalement à ta question, mais met en évidences quelques différences.

      • [^] # Re: Je profite de ce troll

        Posté par  . Évalué à 6.

        J'ai la page de stgit ouverte depuis quelques jours dans mon navigateur mais j'arrive pas bien à comprendre ce que ça fait et quels sont les avantages.

        Est-ce que tu peux en dire un peu (ou beaucoup) plus sur cet outils?

        • [^] # Re: Je profite de ce troll

          Posté par  . Évalué à 5.

          T'inquiète, tu n'es pas le seul

          DLFP

          • [^] # Re: Je profite de ce troll

            Posté par  . Évalué à 10.

            J'ai du mal à voir l'image, tu aurais pas une version un petit peu plus grande ?

            • [^] # Re: Je profite de ce troll

              Posté par  . Évalué à 2.

              C'est pas ma faute si le nouveau moteur de DLFP redimensionne comme un manche.

              Le source originale s'affiche correctement.
              Mais si tu me donnes la syntaxe pour corriger mon commentaire je prends.

            • [^] # Re: Je profite de ce troll

              Posté par  . Évalué à 3.

              Mauvais navigateur => Changer de navigateur.

              Ca passe très bien sous FF et IE 8 et ca jure sous Chrome.

              • [^] # Re: Je profite de ce troll

                Posté par  . Évalué à 1.

                Chezmoiçanemarchepassousfirefox.fr

                Notez le ç permis par le TLD .fr.

        • [^] # Re: Je profite de ce troll

          Posté par  (site web personnel) . Évalué à 3.

          stgit et mq permettent de gérer (comme quilt) des piles de patches. C'est un peu plus puissant que des commits car on peut très facilement les modifier, changer leur ordre, fusionner, découper, etc. Le but est de travailler sur des patches qu'on modifie jusqu'à avoir une fonctionnalité propre avec un historique propre.

          L'exemple tout bête c'est : j'ai un programme client serveur (par exemple une appli web). Je rajouter une action côté serveur, une ressource rest par exemple. Je la code, je fais un commit. Ensuite je code la partie cliente, je commit. Et là je me rend compte que finalement il manquait une broutille, il y avait une petite erreur, etc dans la partie serveur. En temps presque normal, les gens font un commit qui corrige le premier. Ben là non, on dépile le dernier commit, on met à jour le serveur, on rempile.

          Je ne dirais pas que c'est utile tout le temps, mais parfois c'est vraiment vraiment sympa de pouvoir, facilement, travailler sur toutes les couches sans problème. Et une fois qu'on est satisfait, on les transforme en commit et on peut pusher.

          • [^] # Re: Je profite de ce troll

            Posté par  (site web personnel) . Évalué à 4.

            Moui bah tu peux faire une topic branch, la rebase en interactif sur master au moment de reverser l'évolution et réordonner les commits. Pas besoin d'une surcouche à git.

            • [^] # Re: Je profite de ce troll

              Posté par  . Évalué à 2.

              Le rebase interactif ne résout pas tout. Il m'est déjà arrivé de vouloir inverser des commits et finalement de devoir laisser comme ça car les merges devenaient trop complexes. Peut-être de pouvoir faciliter le travail sur un ancien commit peut être intéressant… En tout cas je comprend mieux le cas d'utilisation.

            • [^] # Re: Je profite de ce troll

              Posté par  (site web personnel) . Évalué à 3.

              C'est bien, tu as justement pointé une grosse différence entre les deux solutions :

              au moment de reverser l'évolution

              C'est donc deux façon de faire très différentes. Dans le cas d'un rebase interactif comme tu l'entends, on va nettoyer l'historique à la fin, au moment de merger. Dans le cas que j'exposais, on se soucie d'avoir un historique propre et cohérent pendant le développement. Et ça change tout.

              Et en plus, côté facilité et confort d'utilisation on est quand même vraiment très loin. Stgit est beaucoup plus agréable à utiliser que rebase -i. Dans les trucs utiles, les piles de patches ça permet aussi d'avoir des patches non appliqués. Par exemple avoir toujours un patch final contenant une conf particulière. Lorsque je développe je l'applique, lorsque je commit/push, il ne l'est pas. Peut-être y a-t-il d'autres moyens, mais celui-ci est vraiment pratique.

              • [^] # Re: Je profite de ce troll

                Posté par  (site web personnel) . Évalué à 2.

                Dans le cas d'un rebase interactif comme tu l'entends, on va nettoyer l'historique à la fin, au moment de merger.

                Attention astuce : on paye pas plus cher si on fait un rebase -i dès qu'on a repéré qu'on a oublié un truc dans l'antépénultième commit.

                Ensuite pour l'histoire que le réordonnancement est plus simple qu'avec un rebase ; il fait comment quand t'as vraiment des changements non inversibles, stgit, il devine ton intention ? Cool je vais pouvoir arrêter de coder si l'outil le fait à ma place !

                Par exemple avoir toujours un patch final contenant une conf particulière. Lorsque je développe je l'applique, lorsque je commit/push, il ne l'est pas. Peut-être y a-t-il d'autres moyens, mais celui-ci est vraiment pratique.

                C'est le seul truc où je veux bien envisager que c'est mieux. A priori je ferais ça avec des stashs, qui n'est pas le truc le plus souple de git.

      • [^] # Re: Je profite de ce troll

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        dans mercurial la branche n'est qu'une méta donnée d'un commit. Pour qu'une branche existe il faut au moins un commit. Dans git une branche est un pointeur vers un commit. Pas besoin de commit dans la branche pour qu'elle existe, plus simple pour créer plusieurs branches depuis un même état.

        En fait, tu as la même chose que Git dans Mercurial : les "branches" de Git s'appellent les "bookmarks" dans Hg. Dans Hg, on a donc presque le fonctionnement de Git. Le seul souci c'est que les bookmarks sont assez récents (2-3 ans je crois), et ils ne sont pas toujours pris en compte par certaines commandes…

        • [^] # Re: Je profite de ce troll

          Posté par  (site web personnel) . Évalué à 1.

          Hum, pas exactement si je ne me trompe pas. J'avais eu pas mal de problèmes avec les bookmarks, j'ai jamais vraiment réussi à retrouver le confort de git sur ce point.
          Il faudrait que je refasse des tests, mais c'était pas génial.

      • [^] # Re: Je profite de ce troll

        Posté par  (site web personnel) . Évalué à 2.

        Je reprends la partie sur les branches. Mercurial autorise plusieurs types de branchements :

        Le clonage

        Tout comme git, on peut cloner le dépôt localement. Avec l'utilisation des liens durs, ça ne prend quasiment pas plus de place.

        La branche anonyme

        Les deux le font. Il suffit d'aller à une changset donné et d'y faire un commit.

        La branche nommée

        Seul mercurial le fait. Cela fonctionne comme un tag, une métadonnée dans les changeset mais qui se propage au fil des commits. Je trouve dommage que git ne l'implémente pas, car cela fait toujours un moyen de plus pour gérer les développements.

        La branche git / Le signet mercurial

        La fonctionnalité de git est implémentée par le bookmark chez mercurial. Ça fonctionne de la même façon : le truc avance au fur et à mesure des commits mais n'est pas dans les métadonnées. Je ne sais pas où ça en est chez git, mais chez mercurial le bookmark peut être soit local (ne survit pas au push, seul la branche anonyme voyage) soit être public. Un bookmark public doit être volontairement chargé (_pull_) pour être visible localement.

        Du coup, merci de corriger sinon, mercurial permet de bosser à la git et avec les branches nommées en plus.

        • [^] # Re: Je profite de ce troll

          Posté par  (site web personnel) . Évalué à 7.

          La branche nommée
          Je trouve dommage que git ne l'implémente pas

          Pourquoi ?

          La fonctionnalité de git est implémentée par le bookmark chez mercurial. Ça fonctionne de la même façon

          hum, pas tout à fait…

          Petit exemple à la con dans les deux systèmes :

          • une branche
          • on crée deux topic branches / bookmarks
          • on commit dans les deux
          • on cherche à revenir sur la branche initiale et on merge

          hg :

          hg init
echo "plop" > plop.txt && hg add plop.txt && hg ci -m "Plop"
hg bookmark book1
hg bookmark book2
hg up book1
echo "book1" >> plop.txt && hg ci -m "book1"
hg up -C book2
echo "book2" >> plop.txt && hg ci -m "book2"

          Comment je reviens à la racine commune initiale pour merger ?
          Ben je peux pas facilement car tip s'est déplacé.

          hg glog -q
@  2:1e6b0920866c
|
| o  1:2916c74c15d8
|/
o  0:1c8a265ec97f

          Evidemment là c'est un cas simple, mais dans un cas plus compliqué c'est vraiment galère pour se déplacer.

          Maintenant git :

          git init
echo "plop" > plop.txt && git add plop.txt && git ci -m "Plop"
git co -b branch1
git co master
git co -b branch2
git co branch1
echo "branch1" >> plop.txt && git ci -am "branch 1"
git ci branch2
echo "branch2" >> plop.txt && git ci -am "branch 2"

          A ce moment là, si je veux merger depuis la racine commune c'est très simple puisqu'il me suffit de faire un git co master.

          Les bookmarks en hg c'est juste un label sur une branche anonyme. On le voit d'ailleurs très bien dans l'historique.

          Et pour ceux qui ont utilisé hg < 1.6 on ne pouvait juste pas push/pull les bookmarks

          Ha oui, et ne surtout pas oublier de rajouter cela à votre .hgrc. Sans cela, même pas la peine d'essayer les bookmarks :

          [bookmarks]
track.current = True

          D'ailleurs la description est très marrante : It is possible to obtain a more Git-like experience

    • [^] # Re: Je profite de ce troll

      Posté par  . Évalué à 6.

      Le gros avantage de mercurial sur git, c'est que git est une horreur a apprendre pousse par des integristes dont on a l'impression qu'ils ont tout fait pour emmerder ces lamer de lusers.

      Qu'on ne se meprenne pas, j'utilise git au quotidien depuis un bail et j'en suis maintenant ravi, mais bordel, ca a sacrement pique au debut.
      Hg a une courbe d'apprentissage bien plus douce, on te balance pas brut de fonderie devant un rebase foireux ou tu vas atomiser ton repo local sans le vouloir.
      Sur mac, machg existe depuis un bail et est plutot bien foutu, tout en restant simple. Il a fallu pas mal de temps pour voir arriver gitbox dans la meme categorie, le reste me donnant mal a la tete rien qu'a regarder l'interface.

      J'ai fait un training git recemment a des gens qui sont pas les "couteaux les plus aiguises du tirroir" comme disent nos amis anglophones, v'la le desastre complet. Hg aurait ete bien plus en douceur en les emmenant de svn vers le decentralise.

      Mais. Git a gagne la bataille de popularite, merci github (la question est est ce que github aurait pu s'appeler hghub, et ca j'en sais rien), et c'est bien cool d'avoir hg en interne, si c'est pour utiliser git sur les projets externes, ca m'avance pas des masses.

      Au niveau features, git fait tout, hg fait l'essentiel. Ca depend du contexte, t'as des cas ou la simplicite d'utilisation va primer sur des features que t'utiliseras probablement jamais.

      Un gros truc que je reproche a hg, c'est le case folding. Change la casse sur un nom de fichier sur un fs case insensitive et t'es parti pour t'amuser un bon bout de temps…

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

      • [^] # Re: Je profite de ce troll

        Posté par  . Évalué à 8.

        Hg a une courbe d'apprentissage bien plus douce

        Petit retour d'expérience : je suis dans un labo où les gens n'utilisaient pas de gestion de version pour leur code (ce sont des chercheurs, pas informaticien), une très petite minorité utilisaient SVN.

        J'ai installé un serveur git et mercurial, parce que une équipe voulait git (certains de leurs projets sont sous git chez des partenaires), mais j'étais plus à l'aise avec mercurial au départ, même si je connais un peu les deux.

        Après un an, une bonne partie du labo s'est mis à la gestion de version. La différence entre les deux est absolument flagrante : alors que mercurial n'a pas posé beaucoup de soucis d'apprentissage, git prend vraiment la tête aux gens au départ.
        Même dans la mise en place, mercurial est beaucoup plus élégant. Juste un exemple : pour mettre en place un serveur de code avec authentification, avec mercurial il suffit d'avoir apache (déjà existant dans mon cas) + le script hgweb.wsgi. Avec git, c'est loin d'être aussi simple…

        Mon commentaire est toutefois à relativisé : j'utilise couramment mercurial… même pour faire des pull/push sur des dépôts git.

      • [^] # Re: Je profite de ce troll

        Posté par  . Évalué à 3.

        je t'offre un "é", c'est de bon cœur.
        j'espère que quelqu'un t'offrira un "è" et ton post deviendra lisible.
        au hasard : "a apprendre pousse par", pousse aussi ! "ca a sacrement pique", heu cœur carreau trèfle ?
        et me parle pas d'un clavier anglais, les lettres sont toutes là, juste en dessous. Et avec le bon dico dans firefox, tu tapes "poussw" il te propose "poussé", "piquz", il te propose "piqué".
        bref c'est faisable, ne serai ce que par respect pour ceux qui te lisent et apprécient le fond.

        • [^] # Re: Je profite de ce troll

          Posté par  . Évalué à -2.

          Merci, c'etait tres interessant.
          T'as quelque chose a dire que je ne sache pas deja sinon?

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: Je profite de ce troll

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Mercurial, ça roxxe du poney parce que:

      • c'est beaucoup plus simple à maîtriser (mais ça on l'a déjà dit)
      • Mq (gestion de pile de patchs) est super puissant et très simple, contrairement à git stash (que je n'arrive toujours pas à aimer…)

      J'utilise git et hg au quotidien (depuis 2011 pour git et 2008 pour hg). Et bien que j'utilise de plus en plus Git, j'utilise encore Hg surtout quand j'ai besoin de gérer des piles de patch (qui peuvent être nécessaire en fonction de la manière dont le projet est géré).

      • [^] # Re: Je profite de ce troll

        Posté par  (site web personnel) . Évalué à 3.

        c'est beaucoup plus simple à maîtriser (mais ça on l'a déjà dit)

        Oui, on le dit beaucoup mais j'en suis pas vraiment convaincu. Je ne trouve pas que mercurial soit plus facile à utiliser que git. Ok, la différence vient peut-être non du frontend mais plus de la staging area, mais à part ça…

        Mq (gestion de pile de patchs) est super puissant et très simple, contrairement à git stash (que je n'arrive toujours pas à aimer…)

        ça tombe bien ce n'est pas équivalent. Regarde du côté de stgit. Et ensuite tu n'auras plus de raisons de rester sous hg…

    • [^] # Re: Je profite de ce troll

      Posté par  (site web personnel) . Évalué à 6.

      J'ai essayé plusieurs fois d'utiliser Mercurial pour mes projets perso, mais le truc ne sait rien faire de base, il faut avoir recours à des extensions : pour éditer l'historique (git rebase -i), faire des commit partiels (git add -p).

      Pour l'histoire des extensions, c'est plutôt un problème de design de l'UI. Il s'agit plutôt de fonctions activées ou desactivées. Sur n'importe quelle machine tu commences par crée ton .hgrc avec ton nom de commit, et tu ajoutes les extensions que tu désires. Cela simplifie l'aide intégrée de Mercurial qui ne liste que les extensions activés, ainsi on ne se perd pas au milieu de millions de fonctionnalités. Aussi certaines "extensions" propose une réponse différente au même problème, ainsi c'est à l'utilisateur de savoir celle qu'il désire activer.

      C'est un peu comme si l'on reprochait à Firefox de ne pas venir avec toutes ses extensions par défaut. Pour toi le rebase est peut-être important, mais il ne l'ai pas forcement pour moi (Simplement parce que c'est un concept un peu plus avancé de la gestion de version), ainsi ce n'est pas visible par défaut.

      Pour git rebase ou les commits partiels j'accorderais une chose, c'est que le mode interactif de mercurial est limité.

      Et il y a des concepts que je n'arrive pas à retrouver (le concept de dépôt distant, git remote)

      git remote, c'est pas juste une fonction qui permet de changer la liste des alias des dépots distant ? Dans mercurial cela s'appelle vim et tu modifies un fichier de configuration en ajoutant ces lignes:

      [paths]
      default=http://depot1
      alias1=http://depot2
      …

      Là c'est juste de l'UI, mais par principe je ne suis pas fan des outils qui font des choses simples à ma place

      Pour le concept de dépôt distant, je n'ai pas compris ce que c'est… Ce n'est pas juste un dépôt dans lequel il n'y a pas de copie de travail ?

      Je ne me considère pas forcement comme un fanboy, et un jour je quitterais très certainement Mercurial pour Git (la victoire du plus gros), mais j'aurais quelques arguments en faveur de Mercurial (subjectif, je n'ai pas touché à git sauf pour des petits patchs tout simple depuis 4 ans)

      Je passe sur le coté "je trouve cela plus simple, je n'ai jamais eu à lire le man de mercurial comparé à celui de git…" qui est hautement subjectif.

      Il y a un truc que j'aime beaucoup dans Mercurial, c'est les phases. Ainsi un commit "phasé" comme étant définitif ne peut plus être rebase/amend ou autre. Cela évite le traditionnel problème de git de "Hey, mais t'a rebase sur des commits distribués à toute l'équipe… on fait quoi maintenant". Ou le traditionnel "Mais, t'as pull des changements que je voulais modifier…"

      La prochaine version de Mercurial devrait commencer à amener le concept d'evolve que je trouve très propre. C'est du rebase/amend mais avec conservation de l'historique (caché) des changements détruits (et avec une relation entre les nouveaux commits rebasés et les anciens). Je m'en sers personnellement depuis quelques mois et c'est vraiment sympathique. (Je sais que git conserve les anciens changset devenu obsolète suite à un rebase/…, mais à ma connaissance git ne conserve pas l'historique et la raison de cette obsolescence).

      Un fanboy de Git pourrait-il m'expliquer ce qu'il aime dans Git et pourquoi cela roxxe du poney ? Surtout niveau fonctionnalités.

      • [^] # Re: Je profite de ce troll

        Posté par  . Évalué à 2.

        Je ne suis pas fanboy de Git.

        Nous avons adopté Git dans notre boite par raison plus que par passion.

        Voici quelques éléments de comparaison:

        Git et les +

        • Possibilité d'avoir des branches et des tags locaux
        • de ne cloner qu'une branche ou de faire un checkout partiel en profondeur
        • les rename tracking basés sur le contenu et avec détection heuristique vs rename tracking explicite (si tu importes 2 e versions du même projet à 2 endroits différents et que merges il se base sur le contenu)
        • la réécriture de l'historique local, le reset et l'amend qui te permettent de préparer tes commits propres. indispensable.
        • le rebase par défaut (pas de plugin)
        • Poser un tag ne crée pas un commit
        • sparse checkout

        Git et les -
        - modèle conceptuel plus complexe (branche de suivi vs branches de travail, merge fast forward, …)
        - un CLI complètement inconsistant avec des options jamais cohérentes
        - EGit encore archi buggué (pas de recursive merge, stash qui ne prévient pas avant d'ecraser de fichiers commité lors de la restauration, history qui plante si commit sans message, ….
        - pas de client graphique Windows potable (msysgit à la rescousse)
        - Pour bosser dans une branche partagée qu'on a fecthé il faut recréer la branche en local alors que le clone te le fait par defaut. Incohérent
        - les hooks sont des process forkés plutôt que des appels de routines

      • [^] # Re: Je profite de ce troll

        Posté par  (site web personnel) . Évalué à 2.

        remote, c'est pas juste une fonction qui permet de changer la liste des alias des dépots distant ? Dans mercurial cela s'appelle vim […]

        Il y a la même chose avec Git, les remote sont configurés dans .git/config, qu'on peut éditer à la main sans problème.

        Un truc que Git fait très bien (je ne sais pas ce que font les bookmarks de Mercurial là dessus), c'est pour chaque « remote », garder une copie locale des branches distantes (« remote-tracking branch »). Si je bosse sur la branche « master », que je publie sur le remote « toto », mais que je récupère les changements upstream depuis un autre remote « tutu », alors « master » est l'endroit où je suis en local dans l'historique, « toto/master » pointe sur le dernier commit que j'ai pushé, et « tutu/master » sur le dernier commit que j'ai fetché.

    • [^] # Re: Je profite de ce troll

      Posté par  . Évalué à 6.

      Je préfère largement à Mercurial à git avec sa ligne de commande pourrie conçue par des autistes de l'interaction homme-machine.

      Après si la simplicité d'utilisation ne t'importe pas, je comprends que tu puisses apprécier git ; de même, on peut aimer utiliser sed comme éditeur de texte.

      J'ai essayé plusieurs fois d'utiliser Mercurial pour mes projets
      perso, mais le truc ne sait rien faire de base, il faut avoir
      recours à des extensions : pour éditer l'historique (git rebase
      -i),

      Ben, tu l'as dit toi-même, il suffit d'activer une extension.
      Est-ce que tu râles contre le noyau Linux parce que les pilotes sont disponibles sous forme de modules ?

      Et il y a des concepts que je n'arrive pas à retrouver
      (le concept de dépôt distant, git remote)

      Oui, c'est vrai, Mercurial ne connaît pas les dépôts distants. Je me demande comment on fait, tiens.

  • # plugin pour faire la migration de tfs vers git.

    Posté par  . Évalué à 3.

    tu parles d'un "plugin pour faire la migration de tfs vers git". Tu peux me donner une source parce que j'ai pas trouvé çà.
    Je pense qu'il va falloir se débrouiller pour migrer les données…

  • # git dans windows : un must have !

    Posté par  . Évalué à 2.

    Quand on installe git sur windows, on a accès à un vrai bash (avec des commandes intégrées comme grep) !

    du coup, bye bye le "cmd"

    • [^] # Re: git dans windows : un must have !

      Posté par  . Évalué à 8.

      C'est pas comme si Cygwin existait depuis belle lurette…

    • [^] # Re: git dans windows : un must have !

      Posté par  . Évalué à 6.

      J'ai hésité à inutiliser ce post, mais en fait il me donne une occasion de dénoncer grave: Msysgit me prend la tête tous les jours au taf, pour debugger mes collègues sous win. Pour une raison d’écosystème d'abord: sensibilité à la casse, de performance ensuite: 5 à 10 fois plus lent que le même sous linux, et pour finir une gestion buggée des chemins longs, qui peut tout simplement mettre en status delete tous les fichiers d'une arborescence profonde. Je précise que ce dernier bug est spécifique à msysgit. Donc, pour rester lent mais fiables, jetez cette bouse de msysgit, et utilisez le package git au sein de cygwin, qui lui est tout a fait correct pour cela, qui lui a le bon gout de ne pas utiliser une API windows périmée depuis 10 ans.

  • # Vous aussi, regardez Microsoft comme un suiveur ! (Coué inside)

    Posté par  (site web personnel) . Évalué à 10.

    Cool, je vais pouvoir montrer à ma hiérarchie que grâce à nos choix stratégiques, même Microsoft™ peine à rattraper son retard sur nous !

    ~~~~~~~~~~> []

    ce commentaire est sous licence cc by 4 et précédentes

  • # Merci

    Posté par  . Évalué à 6.

    Génial, je vais pouvoir clouer le bec au Microsoft-fanboy de ma classe, qui refusait d'admettre le génie de ce cher Mr. Torvalds.
    En plus nous sommes en train de voir en cours les différents systèmes de versionnement, donc le timing est parfait !

    • [^] # Re: Merci

      Posté par  . Évalué à 10.

      Travail bien ton troll et fais un journal compte-rendu ici ;)

  • # Infos de dernière minute !!! FLASH SPECIAL

    Posté par  (site web personnel) . Évalué à 10.

    On m'annonce à l'oreillette que la toute dernière version de Windows 8 est passé subitement à la version 3.7.5, une rumeur sur le web précise qu'il s'agirait d'une erreur de manipulation d'un des developpeurs, lors d'un … je cite 'géhité claune'
    Microsoft dément catégoriquement.

    Vive le dredi !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.