Git: Il paraît que la GUI est notre amie

faire un rebase intéractif ou non => CLI

GUI non, d’après ce que tu dis ensuite ?

Sinon, en vrai IntelliJ/Jetbrains a toujours géré le stash… à sa sauce. Depuis très longtemps ils ont une fonctionnalité nommée « shelf » qui fait la même chose, mais en mieux et en plus puissant. Ils ont ajouté le stash récemment (1 ou 2 ans ? la flemme de vérifier) pour compatibilité avec d’autres clients Git sur le même dépôt. C’est sans doute pour ça que son intégration n’est pas évidente, il est là « au cas où ».

Pour la même raison ils ont ajouté le support du staging dans Git (il y a vraiment des gens qui se servent de ce truc d’ailleurs ?)

GUI non, d’après ce que tu dis ensuite ?

en vrai c’est super récent que j’utilise la GUI pour rebase du coup j’ai encore majoritairement le "réflex" CLI, surtout pour zds.

Niveau GUI, sinon, il y a GitKraken, SmartGit et Fork qui sont sympa. A titre perso je suis à 99% content de GitKraken, il faut commencer à chercher des cas un peu tordus pour qu’il manque des choses (le reflog ?).

Quand je lis ton billet, je me dis qu’en fait, le vrai frein à la compréhension est que Git est un outil complexe qui demande de consacrer un peu de temps à comprendre comment il fonctionne pour ne pas faire n’importe quoi et être efficace avec. Ça me fait dire que la question

Est-ce qu’on comprend mieux ce qu’on fait quand on utilise la GUI (resp la CLI)?

n’est pas du tout pertinente. On comprend mieux quand on réfléchit à ce qu’on fait et qu’on prend la peine de lire de la documentation sur le sujet. Peu importe qu’on utilise la CLI ou la GUI, si on tape des commandes sans les comprendre ou qu’on clique un peu au pif en espérant que ça va faire ce qu’on veut, ça va vite coincer. La seule différence est que la GUI facilite un peu l’exploration, mais en revers peut donner un peu trop de confiance à l’utilisateur qui ne se rend pas compte qu’il ne comprend pas certains concepts fondamentaux. La CLI d’un autre côté à une courbe d’apprentissage plus pentue, mais comme sur un outil comme Git il faut passer par un apprentissage quoiqu’il arrive pour s’en servir sérieusement, c’est un problème relativement mitigé.

Typiquement, quand j’ai lu ça :

Cepus me répond alors qu’il est préférable de simplement faire git stash pour ne pas perdre mes modifications et passer à la suite.

Là je suis perdu, je ne vois pas comment on peut avoir les deux à la fois sans faire un commit. Mais la commande, de manière assez magique, fonctionne : le dépôt revient dans le même état que si j’avais fait un commit et avec une commande que je ne connais pas, vhf arrive à me fournir à la volée le patch à appliquer si ça marche toujours pas.

Et pendant deux ans, cette expérience me laissera perplexe.

Je dois dire que je suis resté un peu perplexe. Un type te donne une commande que tu connais pas, dont l’action te parait floue, et tu ne vas pas lire la doc ? git stash --help donne une description plutôt parlante :

Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.

The modifications stashed away by this command can be listed with git stash list, inspected with git stash show, and restored (potentially on top of a different commit) with git stash apply. Calling git stash without any arguments is equivalent to git stash push. A stash is by default listed as "WIP on branchname …", but you can give a more descriptive message on the command line when you create one.

Difficile de faire plus clair, et c’est complet. Perso quand je vois ta fenêtre de "Stash", je comprends pas du tout ce que ça va faire concrètement, à part que le nom lui-même donne un indice… D’ailleurs, on voit ici qu’avec les sous-commandes, la CLI n’est très certainement pas "à plat". Dans ta GUI, il y a le niveau "repository" en plus (qui doit regrouper tellement de trucs que je suis pas sur de voir ce qu’il apporte en compréhension), par contre la GUI découple stash push et stash pop (ou apply, va savoir ce que unstash fait…) et donc empêche de voir que le stash est une pile FILO.

Même chose avec rebase, tu as dans la description de git rebase --help des petits arbres pour expliquer comment et pourquoi utiliser onto. La CLI de git manque cruellement d’unité est a des bizarreries dégueulasses, mais par contre la doc est là.

L’argument de dire que le man est complet ne tient pas d’ailleurs, t’as clairement pas besoin de tout lire. La section description est ultra parlante. T’as quelque paragraphes un peu techniques dans celui de rebase mais ils ne sont pas cruciaux du tout… Et si vraiment elle te rebute, il y a la page rebase du Gitbook (perso je comprends pas comment on peut utiliser git au quotidien et ne jamais prendre la peine de se cogner le Git book… :-°).

Je trouve que la vraie conclusion de ton billet, c’est pas que la GUI est mieux ou moins bien que la CLI pour apprendre Git (je pense que la réponse à cette question est tellement subjective que ça la rend inintéressante), c’est que la maîtrise d’un outil comme Git ne tombera pas du ciel. Si on ne prend pas un peu de temps pour comprendre qu’un dépôt Git est un arbre orienté de commits et comment jouer avec cet arbre, on agira toujours au pif.

Pour la même raison ils ont ajouté le support du staging dans Git (il y a vraiment des gens qui se servent de ce truc d’ailleurs ?)

Pour être sûr, tu demandes si des gens qui utilisent la CLI se servent de la staging area ? Je me demande plutôt si il y a des gens qui ne s’en servent pas. Si ça t’intéresse je peux détailler mes cas d’usages.

Depuis très longtemps ils ont une fonctionnalité nommée « shelf » qui fait la même chose, mais en mieux et en plus puissant

Tu pourrais détailler les différences qui te font dire que c’est mieux et plus puissant que le stash ? Si j’ai besoin d’un truc plus puissant que le stash, je fais une branche à la volée avec un commit. Ça coûte rien et après t’as accès à tous les outils de manipulations classiques de branches pour jouer avec. Le stash, c’est juste une pile à vaisselle sale très temporaire.

Le coup du stash est vraiment utile car il montre une chose : lorsque tu as une CLI il faut que tu sortes de ta logique "comment résoudre mon problème?" pour aller comprendre comment ça marche en première lecture puis vérifier comment appeler en seconde lecture et à chaque fois soit dans un bash différent soit en supprimant le début de la commande que tu viens d’écrire.

La GUI facilite l’exploration car on peut avoir l’aide soit sous forme de contexte, soit sous forme d’infobulle pour concevoir notre appel. Je n’arrive pas à comprendre comment la GUI aura " en revers [de] donner un peu trop de confiance à l’utilisateur qui ne se rend pas compte qu’il ne comprend pas certains concepts fondamentaux" là où la CLI ne l’aurait pas. Justement le cas du rebase est typique. J’ai confiance en mon rebase en CLI et je chie énormément sur comment je veux l’utiliser dès que c’est plus complexe (parce que bon, soyons clairs entre le man qui te donne des A-B-C et toi qui doit manipuler des graphes multirepo où parfois les pointeurs ne tiennent pas ensemble sur le même écran c’est pas du tout la même chose si tu as pas de contexte). J’étais capable de faire mon rebase avant de passer par la GUI, je pers juste inutillement confiance car il faut se souvenir des options, de l’ordre des arguments et en plus pour faire du "check" c’est un peu plus lourd.

Si j’ai fait mon billet c’est que justement à chaque fois pour ces deux anecdotes j’ai eu un coup de "ah mais en fait ça j’avais pas compris" puis j’ai cherché, j’ai trouvé et… j’ai jamais utilisé le stash et le rebase —onto avec la CLI car c’est trop complexe de manipuler.

L’argument "le stash est un FILO et la GUI le cache" est selon moi un faux argument : dans les faits tu peux tout à fait te passer de cet aspect FILO avec un bon set d’alias. Alias que tu vas probablement recopier quelque part sur stackoverflow d’ailleurs. Du coup à l’usage (et c’est ce qui est important), que cette particularité soit caché par une interface qui te permet d’apply le stash qui est au milieu de la pile, franchement osef. C’est même bien plus pratique.

Pour être sûr, tu demandes si des gens qui utilisent la CLI se servent de la staging area ? Je me demande plutôt si il y a des gens qui ne s’en servent pas. o_O Si ça t’intéresse je peux détailler mes cas d’usages.

Je me demande si des gens qui utilisent Git se servent vraiment de la staging area, oui. Parce que je me suis rendu compte que depuis que j’utilise un client qui ne l’intègre pas, elle me manque tellement peu que je ne sais même plus ce que j’en faisait avant !

Perso je m’en sers comme d’une sorte de sauvegarde / brouillon de commit, pour marquer une partie du travail comme terminé en quelque sorte. Par exemple je vais stage les lignes modifiées d’un fichier qui concernent la tâche en cours et auxquels je ne touche plus, et garder les modifs locales qui rajoutent un log de debug… Je ne stage jamais un fichier en entier, c’est le meilleur moyen de commit son super log "crotte de bique, devrait pas être là".

Donc pour moi c’est 100% du temps.

Le coup du stash est vraiment utile car il montre une chose : lorsque tu as une CLI il faut que tu sortes de ta logique "comment résoudre mon problème?" pour aller comprendre comment ça marche en première lecture puis vérifier comment appeler en seconde lecture et à chaque fois soit dans un bash différent soit en supprimant le début de la commande que tu viens d’écrire.

Je suis désolé, je ne comprends pas cette phrase. Les mots indépendamment, oui, mais ensemble dans une phrase je vois pas ce que tu essaies de dire. En fait, je pense qu’on a fondamentalement une façon différente d’aborder l’apprentissage d’un outil de façon générale. Perso, je me suis cogné le git book avant d’avoir à utiliser git sur un vrai projet.

La GUI facilite l’exploration car on peut avoir l’aide soit sous forme de contexte, soit sous forme d’infobulle pour concevoir notre appel. Je n’arrive pas à comprendre comment la GUI aura " en revers [de] donner un peu trop de confiance à l’utilisateur qui ne se rend pas compte qu’il ne comprend pas certains concepts fondamentaux" là où la CLI ne l’aurait pas.

Ton exemple du rebase est justement un bon exemple. Tu t’amuses un peu avec la GUI, et en tâtonnant sans trop comprendre, tu vas arriver à faire ce que tu veux en lisant les indices qui te sont tendus sur un plateau. Utilise rebase en CLI, et tu vas te manger complètement si t’as pas complètement compris ce qui se passe et quelle opération tu es en train de faire. C’est probablement rarement un vrai problème en pratique si l’interface est bien faite et offre les bonnes explications au bon moment, mais je ne suis pas sûr que ce soit le cas général de toutes les GUI.

parce que bon, soyons clairs entre le man qui te donne des A-B-C et toi qui doit manipuler des graphes multirepo où parfois les pointeurs ne tiennent pas ensemble sur le même écran c’est pas du tout la même chose si tu as pas de contexte.

Là, c’est une question de capacité d’abstraction après (d’ailleurs tu peux remplacer les lettres par des arbres entiers sans rien changer conceptuellement puisqu’ils sont orientés…). Manipuler des arbres un peu grand dans sa tête, c’est pas forcément facile, mais là on retombe dans le critère subjectif. Perso, j’aime bien justement que les exemples soient simples et bien lisibles, parce qu’après c’est ultra simple à généraliser sur un arbre plus complet.

Si j’ai fait mon billet c’est que justement à chaque fois pour ces deux anecdotes j’ai eu un coup de "ah mais en fait ça j’avais pas compris" puis j’ai cherché, j’ai trouvé et… j’ai jamais utilisé le stash et le rebase —onto avec la CLI car c’est trop complexe de manipuler.

Et justement, ma réponse à ça, c’est que le fait que tu n’avais pas compris ne vient pas du fait que tu utilisais la CLI ou la GUI, il vient du fait que tu n’as pas pris la peine de lire la doc. Que ce soit celle du man ou celle dans les infobulles de ta GUI ne change rien.

Hein ? Je sais pas comment tu bosses, mais des stash avec plus que mettons 5 éléments, ça m’est jamais arrivé, et la plupart du temps juste savoir que c’est un FILO me permet de bosser avec le stash de mémoire sans avoir besoin de chercher quoique ce soit. Pas besoin d’alias ou je ne sais quoi pour manipuler la pile en question d’ailleurs…

Je me demande si des gens qui utilisent Git se servent vraiment de la staging area, oui. Parce que je me suis rendu compte que depuis que j’utilise un client qui ne l’intègre pas, elle me manque tellement peu que je ne sais même plus ce que j’en faisait avant !

Ma réponse est similaire à celle de @Stranger, je m’en sers quasiment à chaque commit non trivial comme brouillon de commit. La plupart de mes codes sont assez techniques, donc par exemple je stage les morceaux de codes sur lesquels j’ai déjà revérifié les équations.

Merci @Stranger et @adri1 . Est-ce que vous utilisez un éditeur qui gère l’historique local ? Si oui, ça ne fait pas doublon ?

Personnellement je me sers massivement de l’historique local d’IntelliJ (sur lequel on peut coller des étiquettes), et le cas échéant je commite / modifie mes commits (j’ai tendance à beaucoup modifier mon arbre de commits avant push, vu que c’est très facile pour s’y retrouver, même en ayant plusieurs branches de travail pour tester des trucs).

Est-ce que vous utilisez un éditeur qui gère l’historique local ? Si oui, ça ne fait pas doublon ?

Je suis pas sûr de comprendre ta question. En fait, si j’utilise la staging area, c’est justement pour ne pas avoir besoin de retoucher mes commits après coup. Ou alors j’y vais à coup de rebase interactif et de commit --amend en ligne de commande. J’ai tellement peu le cas d’usage en fait que c’est pas un problème qui se pose pour moi.

Si par "historique local" tu entends celui de l’éditeur lui-même et pas des commits non pushés, c’est juste pas assez pratique par rapport à la staging area quand les changements s’étalent sur plein de fichiers et ne sont pas chronologiques. Avec la staging area, tu découples pas mal la partie codage et le commit lui-même. J’utilise Vim aussi que j’ouvre et ferme sans arrêt, avec des buffers dans tous les sens et potentiellement plusieurs instances, donc peut être que ce que fait IntelliJ remplace bien mon propre worflow mais n’est pas applicable à mon cas.

Perso j’utilise massivement historique local, réécriture et staging.

En plus du cas présenté pour la staging area, je l’utilise aussi beaucoup quand je réécris des commits, à coup de add -p et reset -p. C’est bien pratique d’avoir des modifications en cours sur les fichiers qui ne seront pas intégrées au prochain commit.

J’ai une question que j’ai jamais osé poser (maintenant que vous avez parlés de choses intéressantes) … Et les hooks ? En tant que bon petit développeur (merci ZdS pour ça, d’ailleurs), j’ai mis un commit hook pour faire passer l’ami flake8 avant commit, afin d’éviter les problèmes. Problème, j’ai mis ça dans mon virtualenv, et j’appelle la commande directement: en CLI, je suis dans mon virtualenv, donc pas de problème. Via PyCharm, forcément, no such file or directory. Est ce qu’il y a plus intelligent que:

• Mettre le chemin vers le flake8 situé dans le bin du virtualenv, ou
• Installer flake8 globalement (ce qui, normalement, ne pose pas trop de problème pour flake8, à moins qu’on ne change les règles du jour au lendemain, mais imaginons que ce soit une autre commande beaucoup plus obscure, ça pourrait être le cas)

… Parce que je vous avoue que c’est toujours ça qui m’a empêché d’utiliser une GUI (oui, c’est idiot).

Mettre le chemin vers le flake8 situé dans le bin du virtualenv

Dans les faits il est fortement conseillé, quand on utilise la CLI avec python de faire /chemin/vers/python -m commande plutôt que commande. Donc dans notre cas /chemin/vers/venv/bin/python -m flake8.

Concernant git stash je me souviens qu’en tant que jeune ignorant, je l’utilisais souvent dès que git pull n’était pas content si je me souviens bien. Après j’ai compris ma mauvaise pratique (entre autre car je ne faisais jamais de pop de ce que j’avais stashé).

Récemment, je me suis mis à avoir une utilisation de stash et c’est bien la première fois en quelques années. Je ne dis pas que c’est la meilleure façon de faire mais c’est la meilleure solution que j’ai trouvée.

On est deux collègues qui travaillent sur deux branches mais ma branche était basée sur la sienne. Il se trouve que dans l’entreprise, notre workflow est basé sur rebase et donc très souvent on réécrit l’historique en local (on a jamais de commit de merge). Pour je ne sais plus qu’elle raison j’avais besoin de pull les derniers changements de mon collègue alors que je n’avais pas fini de faire ce que je voulais.

Du coup j’ai stash mes changements, fait un rebase et j’ai pop, et c’était magique.

Concernant le débat CLI/GUI, j’utilise une sorte d’hybride qui s’appelle magit et qui est intégré à emacs. Ce n’est pas vraiment une GUI car il n’y a rien de graphique, c’est juste du texte mais c’est super bien présenté et avec pleins de raccourcis pratiques. Il ne me viendrait pas à l’idée de faire un rebase intéractif en CLI maintenant. Du coup même si m’a compréhension de Git s’est amélioré au fil du temps, j’utilise magit depuis 4 mois et je réalise aujourd’hui que j’aurais beaucoup de mal à revenir à la CLI.

Par rapport à Saroupille, j’ajouterais que magit, en plus de donner un raccourci en une touche pour faire une action, montre aussi à côté quelle est la commande (ou sous-commande) correspondante. Donc en l’utilisant, on va plus vite qu’en utilisant la CLI mais on s’habitue aussi aux commandes "vanilla" de la CLI et le savoir est facilement transposable.