Journal Git a fêté ses 10 ans hier ...

Posté par  . Licence CC By‑SA.
Étiquettes :
56
8
avr.
2015

… et même pas une moule pour relayer cette petite interview de son papa:
http://www.linux.com/news/featured-blogs/185-jennifer-cloer/821541-10-years-of-git-an-interview-with-git-creator-linus-torvalds

Les 10 ans de Git pour changer un peu des bougies, c'est aussi l'occasion de se pencher sur la mémoire de tous ses challengers qui ont rejoint le panthéon des logiciels. Paix ait leur âme.
C'est peut-être aussi l'occasion de ressusciter quelques trolls endormis en mémoire du bon vieux temps, car bon, en lisant cette interview moi j'ai plutôt le souvenir d'un bon vieux syndrome NIH pour justifier sa naissance…

Alors remontons un peu le temps:

Souvenez-vous ! La guerre des DVCS était déclarée. Ce bon vieux Subversion, incapable de rejouer un merge sans ré-appliquer tous les commits déjà traités enterrait enfin ce vénérable CVS.
Le fameux "merge-tracking" nous est venu plus tard avec la 1.5 en introduisant une usine à gaz nommée "mergeinfo".
Mais comme c'était l'avènement des méthodes agiles avec le fameux "trunk dev", on nous chantait les louanges de l'intégration continue en vouant aux gémonies les "Feature Branches".
Vous ne pouvez pas utiliser les branches avec SVN ? On va vous expliquer comment vous en passer (Coluche si tu m'entends) à coup de Feature Toggling ou de Branch by abstration.
Ou comment faire passer un mauvais design pour une killer feature.

La force des DVCS pour plier tout ça ? (outre le travail en local et les temps d'accès): le fameux DAG des commits.

A cette époque, un petit gars nommé Tom Lord nous avait pondu un hack du tonnerre en Perl et parfaitement incompréhensible qui s’appelait Gnu Arch.

Monotone, un autre soft plutôt bien conçu a émergé en C++ avec ce concepts de multiples "heads" associées à une même branche, qui a sans doute inspiré ce vénérable Mercurial.

Darcs écrit en Haskell, avait pris une direction différente. Son auteur, David Roundy nous avait pondu sa brillante théorie des patches. Génialisssime, même si je n'ai jamais vraiment bien compris à quoi ça pouvait servir.

Codeville écrit en python, auquel un certain Bram Cohen qui s'y connait un peu en P2P a participé, nous apportait son algorithme de merge "révolutionnaire".

Visiblement ca ne satisfaisait pas ce cher Linus.
Pas que Mercurial ne se soit lancé pour répondre au besoin.
Pas que Bazar propulsé par Canonical et son controversé mécène ne se soit lancé dans l'affaire en proposant une forge associée.
Il avait le mérite de supporter un mode hybride avec lequel on pouvait choisir entre le mode centralisé (commit dans la même branche avec verrou pessimiste possible) et le mode décentralisé (ceux qui ont connu Clearcase multisite saisiront mieux l'analogie). Mais voilà, il était lent, Canonical représentaient les méchants de l'époque et le temps qu'ils améliorent ses perfs, que Launchpad soit libéré, c'était bien trop tard.
Ce que voulait Linus en fait, c'était Bitkeeper en libre.

On a vu aussi émerger des chimères assez étranges comme svk un hack de SVN en perl qui essayait de le rendre distribué (l'apparentant à Bazaar pour le coup).

Il y a aussi eu ceux arrivés après la bataille:
Ils partaient d'un bon sentiment: décentraliser la gestion des tickets en même temps que celle du code.
Nous avons eu Fossil
et Veracity écrit en C dont l'auteur Eric sink proposait auparavant un outil payant sous Windows (Vault).
L'idée est bonne mais maintenant Git s'est imposé et depuis on l'a castré en le recentralisant avec les tickets dans des forges bien propriétaires qui proposent de gérer ses pull request sur le serveur comme GitHub, Stash ou Bitbucket (Le Stash online).
On ne marcherait pas un peu sur la tête ?

Git les a donc tous balayé. Sa puissance, ses qualités et son architecture y sont pour quelque chose; l'aura de son créateur bien plus selon moi.

Reste un petit goût amer, comment un produit si efficace peut-il avoir une interface en ligne de commande aussi inconsistante, imprévisible sans qu'on l'ait remis à plat ?

  • Vous aussi, ça vous défrise de faire git checkout sur un nom de branche pour l'activer ?
  • Vous aussi, vous vous demandez pourquoi il faut faire un git checkout -b pour créer une branche et un git branch -d pour la supprimer ?
  • Vous aussi, vous oubliez toujours qu'il faut fait un git reset HEAD pour vider l'index ?
  • Vous aussi vous avez bookmarké la moitié de Stack Overflow et vous collectionnez les cheat cheet sur Git ? …

vous n'êtes plus seul:
http://www.saintsjd.com/2012/01/a-better-ui-for-git/

Bon Anniversaire Git !
En attendant la naissance de ton petit frère laissons la parole à ton papa.

Does Git last forever, or do you foresee another revision control system in another 10 years? Will you be the one to write it?

Torvalds: I'm not going to be the one writing it, no. And maybe we'll see something new in ten years, but I guarantee that it will be pretty "git-like." It's not like git got everything right, but it got all the really basic issues right in a way that no other SCM had ever done before.

No false modesty ;)

```

  • # Linus, l'homme au code en or

    Posté par  . Évalué à -8.

    Prochaine commande pour Linus, svp un système de gestion de son potable sous Linux (dommage qu'il ne fasse pas de MAO, ça serait déjà réglé je pense), ainsi qu'un bon système d'init…

    « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

  • # coquille ?

    Posté par  . Évalué à 4.

    « l'aura de son créature bien »
    ce ne serait pas plutôt l'aura de son « créateur »

    Très chouette article en tout cas !

    • [^] # Re: coquille ?

      Posté par  . Évalué à 2. Dernière modification le 08 avril 2015 à 17:13.

      Oui je ne me suis pas suffisamment relu désolé.
      En même temps vu que je parle de chimères ;-)

      si un modo passait par là :

      C'est peut-être aussi l'occasion de ressusciter quelques trolls endormis en mémoire du bon vieux temps, car bon, en lisant cette interview "," moi j'ai plutôt le souvenir d'un bon vieux syndrome NIH pour justifier sa naissance…

      la 1.5 en introduisant une usine à gaz nommée "mergeinfo".

      On va vous expliquer comment s' vous en passer (Coluche si tu m'entends) à coup de Feature Toggling ou de Branch by abstration.

      bien conçu a émergé en C++ avec ce concept s de multiples "heads" associées à une même branche, qui a sans doute inspiré ce
      vénérable [ Mercurial ].

      si j*e n*'ai jamais vraiment bien compris à quoi ça pouvait servir.

      qui s'y connait un peu en P2P " , "a participé"," nous apportait son algorithme de merge "révolutionaire".

      Il y a aussi eu ceux arrivés après la bataille:

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 5. Dernière modification le 08 avril 2015 à 19:52.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # Mercurial

    Posté par  . Évalué à 8.

    Sa puissance, ses qualités et son architecture y sont pour quelque chose; l'aura de son créateur bien plus selon moi.

    Je pense aussi, je ne vois pas ce que git a de plus que mercurial (mais je vois quelques trucs qu'il a en moins :) ) et j'utilise plus git que mercurial.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Mercurial

      Posté par  . Évalué à 10.

      mais je vois quelques trucs qu'il a en moins :)

      On t'écoute :)

      • [^] # Re: Mercurial

        Posté par  . Évalué à 6.

        le principe des phases, la gestion à la mq, un git outgoing,…

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Mercurial

          Posté par  . Évalué à 2.

          le principe des phases

          je suis pas franchement convaincu que ce serait utile à git

          la gestion à la mq

          stgit

          un git outgoing

          git push --dry-run

    • [^] # Re: Mercurial

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 08 avril 2015 à 20:12.

      J'utilise les deux au travail, Mercurial pour les développements internes/clients, Git pour les projets communautaires parce que GitHub.

      En faisant abstraction de son horrible UI, Git permet d'être plus souple au quotidien : quand je fork un dépôt Git pour y contribuer, je peux me permettre de retravailler l'historique de ma branche comme je le souhaite sur mon dépôt perso (y'a peu de chance que quelqu'un l'ait forké à son tour donc je me permet de tout péter à coup de git rebase et git push -f avant de faire la pull request sur le projet upstream). Simple et rapide pour moi dans le cadre des petites contributions, et historique lisible pour ceux qui vont faire la revue de code avant un éventuel merge.

      Par contre j'ai déployé Mercurial dans l'entreprise (pour remplacer SVN) car :

      • UI vraiment bien faite, les commandes sont cohérentes et évoluent en même temps suivant les plugins activés,

      • je suis le seul "barbu" dans l'équipe, et souhaite que le reste de l'équipe soit le plus autonome possible,

      • pas de git push --force, Mercurial ne fait que de l'ajout sur les dépôts distants : quand c'est pushé, c'est pushé ! En cas de grosses erreurs (genre commit d'un mot de passe pas sensé être publié), j'interviendrais à la main dans le dépôt distant et demanderai à ceux ayant déjà pullé de détruire le commit concerné ou refaire un clone. Ce n'est jamais arrivé, et ça relève du cas exceptionnel.
        Bref, que de l'ajout sur les dépôts Mercurial distants, et cela veut aussi dire qu'on ne peut pas perdre des données de l'entreprise accidentellement, et pour moi c'était un critère important.
        Je suppose qu'on peut bien sûr limiter ça avec Git également, mais c'est natif dans Hg.

      • le système de phases :

        • changeset draft (donc pushable, une fois pushé il deviendra public), qu'on affiche en vert dans les logs
        • changeset public (présent sur le dépôt distant, et impossible à modifier/supprimer, une erreur s'afficherait alors), affiché en bleu
        • changeset secret (avec hg ci --secret, rend le changeset local, ne peut être pushé par accident), affiché en rouge

      • hg out / hg in : pour voir ce qu'on peut récupérer, ou ce qu'on peut pusher, ça me manque énormément sous Git.

      Mais je reconnais que le système de branche légère de Git est appréciable, autant que le fait que des changesets non-référencés seront détruits au bout d'un moment, ça procure pas mal de flexibilité à l'usage. Seulement c'est si reposant de travailler avec Hg… l'outil se fait oublier, et mes nerfs me disent merci :)

      • [^] # Re: Mercurial

        Posté par  . Évalué à 5. Dernière modification le 08 avril 2015 à 21:00.

        hg out / hg in : pour voir ce qu'on peut récupérer, ou ce qu'on peut pusher, ça me manque énormément sous Git.

        git log master..origin/master (et vice-versa) non ?

        • [^] # Re: Mercurial

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

          Pas vraiment. git log ne traite que l'historique local. En effectuant ta commande, je ne peux pas voir le travail que mon collègue a réalisé entre temps sur le dépôt distant (et quelle que soit la branche). Du coup il faudrait faire un git fetch au préalable, mais là du coup on perd l'avantage de hg ingoing/hg outgoing qui est justement de simuler un pull/push sans rien toucher à son dépôt local.

          Et puis, autre avantage à ces commandes : autant hg log -p permet d'afficher le diff complet d'un changeset local (équivalent à git show), autant on peut faire pareil avec les changesets qu'on peut pusher (hg out -p) ou - beaucoup plus utile - les changesets qu'on peut récupérer (hg in -p).

        • [^] # Re: Mercurial

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

          Out :

          git log @{u}..

          In :

          git log ..@{u}

          Avec un peu de style ça peut ressembler à un truc comme

          git log --pretty=oneline --abbrev-commit --graph @{u}..

          • [^] # Re: Mercurial

            Posté par  . Évalué à 10.

            Très intuitif, comme toujours !
            Merci pour le tip quand même .

      • [^] # Re: Mercurial

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

        J'ajouterai une petite conclusion à mon commentaire plus haut :
        Même si Git à une UI désastreuse (n'ayons pas peur des mots), je le trouve beaucoup plus adapté pour des développements communautaires, parce qu'il est très flexible. Dans un contexte de travail non-communautaire (donc avec une population de contributeurs qu'on maîtrise) ayant des process de travail bien établis, je préfère Mercurial, simplement car on évite les mauvaises surprises, on forme plus rapidement un nouveau venu, un stagiaire, ou même des non-techos grâce aux GUI matures existantes pour Hg (TortoiseHG notamment).

      • [^] # Re: Mercurial

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

        Hormis github, qui est un argument tout à fait valable, je ne vais aucun avantage à git comparé à mercurial.

        En faisant abstraction de son horrible UI, Git permet d'être plus souple au quotidien : quand je fork un dépôt Git pour y contribuer, je peux me permettre de retravailler l'historique de ma branche comme je le souhaite sur mon dépôt perso (y'a peu de chance que quelqu'un l'ait forké à son tour donc je me permet de tout péter à coup de git rebase et git push -f avant de faire la pull request sur le projet upstream). Simple et rapide pour moi dans le cadre des petites contributions, et historique lisible pour ceux qui vont faire la revue de code avant un éventuel merge.

        Et ? C'est pareil avec Mercurial. Je trouve même que c'est bien plus simple qu'avec Git. Avec mercurial, tu update (checkout) le commit qui t’intéresse, tu commit --amend, puis en utilisant evolve, tous les autres commit sont rebasés par dessus.

        http://mercurial.selenic.com/wiki/ChangesetEvolution

        Tu peux toujours faire du reordonancement et de la suppression avec histedit (qui est l'équivalent à quelques détails de rebase -i).

        La dessus, tu as le système de phase qui t’évite de rebaser des commits publique, donc qui t'evites de te retrouver par erreur après quelques heures de travail avec un dépôt dans un état qui va te prendre quelques heures à rétablir.

        De plus, mercurial (avec evolve) garde l'historique des manipulation d'historique. Ainsi tu peux voir quel est le commit à l'origine d'un amend, ou d'un rebase. Git ne sait pas faire cela et tu dois chercher dans le reflog à la main, ce qui peut être laborieux.

        Hormis quelques détails, comme l'absence d'auto !fixup ou !squash dans Mercurial et que l'ajout interactif d'éléments dans un commit (i.e, l’équivalent de git add -p) est un peu moins élaboré (il existe crecord, mais je n'ai jamais accroché), je suis très souvent frustré par les limitations et le manque de flexibilité de git comparé à mercurial.

        Pour finir, Facebook a dernièrement annoncé qu'il passaient de git à mercurial pour des raison de flexibilité et de performance https://www.youtube.com/watch?v=X0VH78ye4yY et google annonce aussi collaborer avec facebook pour l'évolution de Mercurial.

        • [^] # Re: Mercurial

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

          C'est vrai j'avais oublié evolve. Je m'y étais intéressé l'année dernière, mais l'avais mis de côté car j'évitais les extensions qui ne sont pas fournies en standard ou qui sont expérimentales. Apparemment ce n'est toujours pas fournie en standard ou jugée suffisamment stable, je ne la trouve pas dans la liste http://mercurial.selenic.com/wiki/UsingExtensions. J'attend ça avec impatience car pouvoir réécrire l'historique sans rien détruire, et pouvoir relire ces réécritures, c'est une tuerie.

          Mais ça n'enlève rien à Git qui ne propose peut-être pas cette fonctionnalité, mais qui répond quand même au besoin de beaucoup de dev sur la facilité de réécrire l'historique, et ça depuis qu'il existe.

          • [^] # Re: Mercurial

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

            C'est vrai j'avais oublié evolve. Je m'y étais intéressé l'année dernière, mais l'avais mis de côté car j'évitais les extensions qui ne sont pas fournies en standard ou qui sont expérimentales. Apparemment ce n'est toujours pas fournie en standard ou jugée suffisamment stable, je ne la trouve pas dans la liste http://mercurial.selenic.com/wiki/UsingExtensions. J'attend ça avec impatience car pouvoir réécrire l'historique sans rien détruire, et pouvoir relire ces réécritures, c'est une tuerie.

            C'est à mon sens un problème de communication de la part de l'équipe de Mercurial, c'est qu'ils ont tendance à être très conservateur et le système d'extension donne cette idée que seulement un petit sous ensemble des fonctionnalités sont vraiment correctes et que le reste c'est juste des truc un peu bancales qui marchent plus ou moins. J'ai l'impression qui Git fait un peu l'inverse, c'est à dire proposer un truc en standard, alors que cela marche plus ou moins et corriger dans les version suivantes.

            De ma dernière discussion avec un développeur d'evolve (je ne peux pas prouver cette affirmation cependant), je crois avoir compris que la plupart des composantes d'evolve sont déjà dans le core de mercurial et c'est maintenant plus des problèmes cosmétiques qu'autre chose pour en faire une extension officielle.

            En pratique, j'utilise evolve depuis quelques temps et aucun problème et je connais quelques développeurs qui bossent sur des "petites" base de code de "petites" entreprises "familiales" (genre facebook…) qui l'utilisent quotidiennement sans soucis majeurs.

            Mais ça n'enlève rien à Git qui ne propose peut-être pas cette fonctionnalité, mais qui répond quand même au besoin de beaucoup de dev sur la facilité de réécrire l'historique, et ça depuis qu'il existe.

            Si on enlève evolve, Mercurial est au même niveau que Git sur la facilité de réécrire l'historique.

            • [^] # Re: Mercurial

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

              Si on enlève evolve, Mercurial est au même niveau que Git sur la facilité de réécrire l'historique.

              Je m'auto répond. La seule difference que je vois (et qui est vraiment un problème) c'est qu'au lieu de "cacher" les commits qui disparaissent du fait d'une réecriture (comme le fait git), ils sont supprimés et stockés dans un fichier de backup. Il est vrai que c'est une limitation importante, mais je n'y pensais plus tellement evolve marche bien depuis quelques années.

              • [^] # Re: Mercurial

                Posté par  (site web personnel) . Évalué à 3. Dernière modification le 09 avril 2015 à 15:18.

                Si on enlève evolve, Mercurial est au même niveau que Git sur la facilité de réécrire l'historique.

                Sans evolve il est pourtant impossible de faire un amend/rebase/mq sur des changesets déjà publié, chose que Git autorise. C'est dangereux, mais pour celui qui sait ce qu'il fait ça offre plus de souplesse. C'est ça que je veux dire en disant que Mercurial n'autorise pas la réécriture d'historique par défaut (sans evolve) :

                $ echo paf > pouf
$ hg add pouf
$ hg ci -m "ajout pouf" pouf
$ hg phase -p tip    # pour simuler un changeset déjà pushé ou provenant d'un pull
$ echo paf2 >> pouf
$ hg ci --amend
abandon : cannot amend public changesets

                Ce n'est pas un défaut de Mercurial ou un avantage à Git (tout dépend du besoin recherché), juste que Git autorise le dev à tout péter pour le meilleur et pour le pire, c'est dangereux mais souple.

                • [^] # Re: Mercurial

                  Posté par  . Évalué à 8.

                  En résumé, dans un modèle centralisé, le "force" sur un push non fast-forward est possible avec git … sauf si le serveur le désactive.

                  Si je comprends bien, ce n'est pas le cas avec les "named branch" de Hg. Par contre qu'en est-il de l'extension bookmarks, si on n'utilise que celle-ci et pas de "named branch" ?

                  Ce point est quand même assez important car on peut mettre en place certains workflows dans lesquels une "feature branch" est réservée à un développeur par convention. Ça lui permet de valider son dev avec toute la batterie de tests sur le serveur de build et de la réaligner autant qu'il veut en forçant le push avant de l'intégrer, contrairement aux pull request classiques à le Github.
                  Au moment de l'intégration, il n'a plus qu'un merge --no-ff à faire et la branche de feature n'est pas polluée par des merges d'intégration en provenance d'upstream une fois qu'il a déjà pushé.
                  Du coup on obtient un historique très propre avec des features branches très lisibles.

                  CrEV a bien décrit ce workflow dans un journal.

    • [^] # Re: Mercurial

      Posté par  . Évalué à 4.

      Utilisateur de Mercurial, je constate qu'il y a des avantages à Git (VS Mercurial). J'aime beaucoup l'argumentaire de Michael Bayer, le papa de SQLAlchemy expliquant pourquoi ce projet a migré de Mercurial vers Git: http://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrated-to-git/, qui rejoint partiellement le commentaire ci-dessous de Seb.
      Au delà des aspects techniques – et Git semble avoir de très solides arguments –, à mes yeux son principal avantage est sa base d'utilisateurs, propulsée par GitHub. Ce n'est pas pour rien que Bitbucket a introduit Git comme système de gestion de version alternatif à Mercurial, et ce depuis 2011 ;-|

      • [^] # Re: Mercurial

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

        Outre Github, maintenant beaucoup d'outils ne proposent que git comme interface. Si je veux une forge à peu près moderne à installer chez soi, je ne vois que Gitlab qui soit à mon goût, et qui (Ô surprise) ne sait pas faire avec Mercurial. Si je ne me trompe pas, mon IDE sait uniquement faire du SVN et du Git par défaut (j'avoue que ça fait longtemps que je n'ai pas touché à la conf, donc je peux me tromper), même s'il y a un plugin pour Mercurial.

        Même si je serais volontiers passé de svn à Mercurial, cette différence de traitement dans les outils a fait pencher la balance en faveur de git.

  • # .

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

    Il faut quand même être honnête sur les défauts de l'UI :

    • dans (presque) chaque nouvelle version mineure il y a des changements pour l'améliorer et notamment diminuer les incohérences
    • il y en a suffisamment pour ne pas en ajouter : git branch -d ne fait que supprimer une branche alors que git checkout -b la crée et passe dessus. Ce qui du coup est à peu près cohérent avec git checkout qui passe sur une branche existante. La vraie réciproque de git branch -d qui crée simplement une branche, bah… c'est git branch. Du coup sans être parfait ça me parait moins terrible que comme tu l'as présenté. Un vrai débat par exemple ça serait de demander pourquoi pas git branch --checkout plutôt que git checkout -b seulement là comme c'est une vraie question, je ne connais pas assez les arcanes de git pour savoir lequel est le plus légitime (et si on ajoute les deux pour faire plaisir y aura quelqu'un pour dire "olol y a plusieurs façons de faire ça pue").

    • [^] # Re: .

      Posté par  . Évalué à 1.

      Je pense être honnête et le fait que git évolue par petite touche est au contraire contreproductif. Ca oblige à conserver une compatibilité ascendante en rajoutant de la complexité. Ce dont on aurait besoin c'est une vraie remise à plat.

      Oui git branch ma-branche permet maintenant de créer une branche depuis quelques temps mais c'est encore un rafistolage.
      Pourquoi git tag mon-tag existe depuis le début, pourquoi pas git checkout --tag pour créer un tag à la volée ? Après tout, c'est une référence aussi.

      Mon sentiment, c'est qu'il y a déjà pléthore de commandes qui se recoupent et on est bien loin de la philosophie unix là. checkout devrait checkouter et pas créer de branche. On n'ose plus rajouter de commandes alors on multiplie les options.

      Et ce n'est qu'un exemple parmi tant d'autres.
      pour pusher un dépôt on ne peut toujours pas combiner --tags et --all dans la même commande (d'ailleurs --all devrait inclure les tags), …

      Bref à force de se contorsionner on ne fait même plus attention à ses défauts.

      Si tu veux voir un CLI bien propre, je t'invite à lire le man de Clearcase.
      Les métadonnées étaient correctement définies et offraient une interface consistante.

      • [^] # Re: .

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

        Oui git branch ma-branche permet maintenant de créer une branche depuis quelques temps mais c'est encore un rafistolage.
        Pourquoi git tag mon-tag existe depuis le début, pourquoi pas git checkout --tag pour créer un tag à la volée ? Après tout, c'est une référence aussi.

        Euh désolé Maurice mais le bouchon commence à râler là. git branch et git tag créent des références mais sans toucher à ta copie de travail. git checkout manipule la copie de travail. Alors OK pourquoi pas un git checkout -t pour raccourcir git tag x && git checkout x comme git checkout -b raccourcit git branch x && git checkout x si y a de la demande… sauf que checkout un tag ça finit en detached head et c'est pas le but de git… mais en tout cas comparer des choux et des carottes (commandes qui manipulent des refs et commandes qui manipulent la copie de travail) ça aide pas la crédibilité.

        Si tu veux voir un CLI bien propre, je t'invite à lire le man de Clearcase.

        Non merci j'ai déjà pas assez de temps à consacrer à notre super écosystème libre, je vais pas en plus investir dans du proprio IBM. Pourquoi pas lire le MSDN tant qu'on y est ?

        • [^] # Re: .

          Posté par  . Évalué à -1.

          mais en tout cas comparer des choux et des carottes (commandes qui manipulent des refs et commandes qui manipulent la copie de travail) ça aide pas la crédibilité.

          Oui et git checkout fait les 2, tout à fait dans la philosophie d'unix. Tu parles de crédibilité. Le CLI de Git ce sont juste des hacks construits au fil de l'eau (avant la réécriture en C) et en y rajoutant des options pour les cas tordus pas prévus au départ.

          Ca ferait du bien à tous ces cadors de Git de l'admettre mais avec un peu de simplicité, ils y perdraient de leur prestige, on a bien compris.

          • [^] # Re: .

            Posté par  (site web personnel) . Évalué à 2. Dernière modification le 10 avril 2015 à 21:53.

            git checkout fait les 2

            Uniquement avec le raccourci git checkout -b qui continue à modifier la copie de travail (le principe de checkout) tout en créant une ref, parce que "créer une branche et l'utiliser immédiatement" est de manière assez évidente un cas d'utilisation très utile et répandu. Là-dessus, juste pour cracher sur git, tu voudrais rajouter toutes les combinaisons possibles de manipulations, notamment un cas complètement tordu, "je veux créer un tag et détacher HEAD pour le positionner dessus" (évidemment vue la souplesse de git il y a peut-être des cas où c'est utile à des gens mais c'est d'une utilité de plusieurs ordres de grandeur en dessous de la création de branche à utiliser immédiatement).

            Ca ferait du bien à tous ces cadors de Git de l'admettre mais avec un peu de simplicité, ils y perdraient de leur prestige, on a bien compris.

            Oui on a bien compris que tu es un peu trop limité pour arriver à utiliser git, et qu'en conséquence tu déverses ton fiel dessus ou sur ceux qui sont corticalement suffisamment frisés pour arriver à l'utiliser efficacement. Moi aussi j'aime bien les attaques personnelles.

  • # Fossil

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

    Franchement, pour utiliser Fossil au quotidien il n'y a pas photo : c'est bien plus simple, rapide, léger, efficace et tout ce que vous voulez que git.

    Et c'est vraiment décentralisé, n'importe qui peut lancer un serveur en 1 seconde. Et ça gère les tickets. Et y'a une API REST. Et y'a un wiki. Et la doc du projet est intégrée. Et ça gère les droits des utilisateurs. Et 1000 autres choses. Dans un tout petit binaire, avec une syntaxe très cohérente et simple à apprendre.

    Bref c'est génial. Qui voudrait encore utiliser cette horreur de git ?

    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: Fossil

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

      Franchement, pour utiliser Fossil au quotidien il n'y a pas photo : c'est bien plus simple, rapide, léger, efficace et tout ce que vous voulez que git.

      Ca ça me fait toujours marrer. Attaquer git sur son UI OK, mais sa rapidité ou sa légèreté, faut oser. Benchmarks ?

      • [^] # Re: Fossil

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

        Une impression personnelle, il n'existe pas à ma connaissance de benchmark qui indique que l'un ou l'autre soit plus rapide, mais bon je constate au quotidien, surtout quand il faut faire des synchros en GPRS, ça va bien mieux avec fossil !

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

        • [^] # Re: Fossil

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

          Une impression personnelle, il n'existe pas à ma connaissance de benchmark qui indique que l'un ou l'autre soit plus rapide

          Forcément, pour git il y a des benchmarks de Google / twitter / Atlassian / … qui utilisent git sur des dépôts de l'ordre de la dizaine de Go, du million de fichiers et de la centaine de milliers de commits, et certes il peine un peu. De l'autre on a des impressions d'utilisateurs de Fossil sur des dépots de 10 commits avec 5 fichiers totalisant 100ko. Je crois qu'à cet ordre de grandeur SVN et CVS sont rapides aussi.

          • [^] # Re: Fossil

            Posté par  . Évalué à 1.

            SVN et CVS sont limités par les performances réseau pour beaucoup d'opérations (notamment les très utiles log et annotate), ce qui n'est pas le cas d'un DVCS, fût-il mal optimisé.

    • [^] # Re: Fossil

      Posté par  . Évalué à 3.

      Je t'invite à jeter un coup d'oeil à Veracity si tu es fan de ces outils.
      Pour une comparaison… biaisée:
      http://veracity-scm.com/compare/

      • [^] # Re: Fossil

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

        Yep Veracity est très bien, mais plus développé, la dernière version a 2 ans, la mailing list est morte, et le site de support (questions) est en 404 depuis longtemps.

        C'est dommage mais bon d'un autre côté Fossil avance relativement bien, à une allure assez rapide, avec des dévs relativement dispos, talentueux et sympas.

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: Fossil

      Posté par  . Évalué à 2.

      C'est surtout pas les mêmes besoins.
      Pour des petits projets, Fossil est parfait.

      • [^] # Re: Fossil

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

        Pour de gros projets, fossil est parfait aussi ;-)

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

        • [^] # Re: Fossil

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

          N'éxagérons rien :) Pour avoir tester le dépôt NetBSD sous fossil et sous git, fossil est quand même horriblement plus lent (même si il a par ailleurs de nombreuses qualités). Même le(s) devéloppeur(s) le reconnait.

  • # Git branch

    Posté par  . Évalué à 3. Dernière modification le 21 mai 2015 à 13:32.

    Un grand merci, à mon tour (et un peu tard), pour ce journal de qualité qui me révèle l'étendue de mon ignorance dans le domaine alors même que j'utilise des logiciels de versioning comme tout le monde et de longue date (en ayant commencé avec CVS).

    Cela dit :

    Reste un petit goût amer, comment un produit si efficace peut-il avoir une interface en ligne de commande aussi inconsistante, imprévisible sans qu'on l'ait remis à plat ?

    Vous aussi, ça vous défrise de faire git checkout sur un nom de branche pour l'activer ?
    Vous aussi, vous vous demandez pourquoi il faut faire un git checkout -b pour créer une branche et un git branch -d pour la supprimer ?

    Pas vraiment puisqu'en réalité, ce ne sont pas les commandes officielles pour faire cela mais des raccourcis bien pratiques. Et si tout le monde les prend en exemple, c'est bien parce que les développeurs les utilisent et qu'ils ont une raison d'être.

    L'interface de Git, c'est un peu comme le jeu « Pyramide ». Personne ne comprend de quoi il s'agit, jusqu'au moment où on explique qu'il s'agit simplement de trouver des mots en rapport avec d'autres dans un contexte donné (celui-là même qui manque en général). Du coup, les commandes servent chacune à gérer un thème en particulier, et ont un comportement par défaut :

    git branch → Affiche les branches existantes ;
    git branch nomdebranche → Crée une branche ;
    git branch -f nomdebranche → Force la création d'une branche (sémantique habituelle de -f) ;
    git branch -d nomdebranche → Efface une branche (delete) ;

    Présenté comme cela, ça se tient. Les options « -b » et « -B » de checkout permettent ensuite de faire cela à la volée, parce qu'on fait rarement l'un sans l'autre.

    J'avais essayé ce tutoriel : http://pcottle.github.io/learnGitBranching/ bien pratique pour se faire la main quand on part de rien (Je n'arrive plus à savoir, malheureusement, si je l'ai découvert ici, sur la tribune ou en cherchant des tutoriels par moi-même…).

    Cela dit, j'admets que cela concerne uniquement « branch » et que l'on pourrait disserter longtemps sur la pertinence du reste du langage de git.

    Vous aussi vous avez bookmarké la moitié de Stack Overflow et vous collectionnez les cheat cheet sur Git ? …

    Je suis obligé de dire que oui. :-)

Suivre le flux des commentaires

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