Journal Gérer son espace de travail git avec "gws"

Posté par  . Licence CC By‑SA.
Étiquettes :
49
20
fév.
2015
Ce journal a été promu en dépêche : Gérer son espace de travail git avec "gws".

Amis du soir, bonsoir.

Cela fait maintenant plus d'une année que j'utilise un outil de ma création, qui se trouve être — de mon point de vue — fort utile. Un petit brin de perfectionnisme et un petit manque de confiance m'ont, jusqu'à aujourd'hui, pousser à remettre au lendemain sa diffusion.

Aujourd'hui, je saute le cap, je prends mon clavier et j'écris (bépo le clavier, bien sûr). N'étant pas fou, j'ai tout de même pris le soin de le partager avant sur /r/archlinux — la communauté y étant moins corrosive qu'ici — pour avoir un premier retour.

Qu'est ce que c'est?

gws est un outil KISS (script bash, zsh compliant) pour gérer de manière simple un espace de travail (workspace) composé de plusieurs dépôt git. Ça ne vous parle pas et vous semble être un pitch commercial? Laissez-moi l'aborder autrement:

Si vous vous reconnaissez dans quelques-unes de ces questions, cet outil pourrait vous être utile:

  • Vous avez un dossier ~/dev/, ~/code/ ou ~/workspace/ dans votre home?
  • Vous y avez cloné dedans plein de dépôts git?
  • Vous ne savez jamais quels dépôts, branches, commits n'ont pas été synchronisés?
  • Vous en avez marre d'avoir à faire 17 pull manuellement le lundi matin au boulot?
  • Vous déprimez en arrivant dans le train de voir que vous n'avez pas récupéré votre dernier projet sur votre ordinateur portable?

Comment ça marche?

  1. Premièrement créez dans votre répertoire (~/dev/ par exemple) un fichier .projects.gws avec un contenu de ce style (que vous adapterez à vos besoins bien sûr):
tools/coursera-dl | https://github.com/dgorissen/coursera-dl | 
tools/peru | https://github.com/buildinspace/peru | 
tools/q | https://github.com/harelba/q | 
work/docker-gitlab | https://github.com/sameersbn/docker-gitlab.git | 
work/neuraltalk | https://github.com/karpathy/neuraltalk.git |
  1. Lancez gws update qui va clone tous les dépôts manquants: gws update
  2. Hackez un peu!
  3. Lancez gws pour voir l'état de votre espace de travail (dépôts, branches) en un clin d’œil: gws update
  4. Faites éventuellement un pull fast-forward (Oui j'en ai marre de franciser les termes techniques, c'est abject.) avec la commande gws ff. Vous aurez ainsi avec vous la dernière version de tous vos projets. Très utile avant de partir prendre le train.
  5. Avant de partir du boulot, faites un petit gws à nouveau pour être sûr que vous avez bien synchronisé tous vos changements, par exemple pour retrouver vos fichiers de configurations en arrivant à la maison.

Il y a bien quelques possibilités en plus mais je vous laisse le soin de lire le README (en anglais) pour la liste exhaustive des possibilités. Juste un petit teasing rien que pour vous:

  • La commande gws est utilisable depuis n'importe quelle endroit de l'espace de travail.
  • Vous pouvez créer plusieurs espaces de travail différent, faites plusieurs dossiers avec chacun son propre .projects.gws
  • En versionnant le fichier .projects.gws sur github par exemple vous pouvez vous retrouver avec exactement le même workspace sur tous vos ordinateurs.
  • Si vous le versionnez, vous pouvez même rajouter le dossier courant (. | … |) dans le fichier .projects.gws pour le surveiller aussi.
  • Il y a possibilité de mettre un fichier .ignore.gws que vous ne versionnerez pas pour filtrer avec des regex certains projets — par exemple les projets du boulot à la maison.

Où je le trouve?

  • Site web
  • Github
  • Il est packagé pour Arch Linux
  • Et pour les autres distributions, c'est un simple script bash, mettez le quelque part dans votre $PATH. Ou mieux, faites-en un paquet.

PS: Et pour répondre d'avance à la question: «Un script bash de 830 lignes, t'es malade?» je vous réponds: YOLO1.

  1. Mais oui si c’était à refaire je choisirais un autre langage. C'est impossible à maintenir un script bash de cette taille. J'ai dans l'idée, un jour, de le réécrire dans un autre langage et de supporter plus de VCS (mercurial, svn, …) et plus d'options. Un jour… qui sait. ↩

  • # KISS

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

    Beau travail , ça va m'aider au boulot.
    Cependant, tu utilises l'expression KISS de manière trop publicitaire. D'autant qu'il n'y a pas de lien entre une application KISS et l'usage du shell contrairement à ce que tu sembles sous entendre.

    • [^] # Re: KISS

      Posté par  . Évalué à 10.

      Hum c'était dans le sens où il y a juste un fichier de configuration, un fichier texte, dont la syntaxe est très simple. Mais oui c'est un peu buzzword. Disons que ceux qui aiment les logiciels qui ne font qu'une chose, qui le font bien, et de manière simple, vont tilter que ça pourrait les intéresser.

  • # gitcheck

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

    si c’était à refaire je choisirai un autre langage

    gitcheck en python, permet juste de vérifier les modifications. Peut-être une source d'inspiration pour ta réécriture …

    https://github.com/badele/gitcheck

    wind0w$ suxX, GNU/Linux roxX!

    • [^] # Re: gitcheck

      Posté par  . Évalué à 3.

      Je ne connaissais pas. Je vais le garder dans un coin de ma tête si je m'y mets un jour. Merci

    • [^] # Re: gitcheck

      Posté par  . Évalué à 2.

      Merci pour le lien, j'ai adopté.
      L'outil proposé dans ce journal est + complet, mais gitcheck a le bon goût de n'avoir rien à configurer pour fonctionner avec mon workspace.
      Tu installes, ça marche.

  • # Si tu montres à un vrai geek un super truc sur ton ordi, il regardera tout le reste sauf ça

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

    C'est quoi ton terminal/PS1 ?

  • # repo

    Posté par  . Évalué à 4.

    Yop

    Quelle est la différence entre ce que tu proposes et android-repo ? Finalement, tes .projets.gws ressemblent vachement a des manifestes repo.

    A la limite, je trouve que ton interface ncurse est sympa, mais a premiere vue il était tout a fait possible de faire pareil sur du repo.

    Du coup, quel avantage voyais tu a ne pas te baser sur repo ?

    • [^] # Re: repo

      Posté par  . Évalué à 5.

      Je n'ai jamais entendu parler de repo avant, peut-être parce que je ne fais pas de dev Android!? Donc je n'ai pas pu penser à me baser dessus.

      À vrai dire je n'ai pas vraiment cherché ni vérifié si il existait des alternatives lorsque j'ai commencé à développer ce script. Ça à plutôt commencé par un script bash débile de quelques lignes pour mon usage uniquement, et il a fini par évoluer vers ce qu'il est aujourd'hui. C'est donc fort possible qu'il existe des alternatives qui marchent bien mieux, et il y avait sûrement des manières plus optimales de le faire. Je n'ai aucune prétention sur ce script ;-)

      À première vu (après avoir lu la page de doc) je pense que tu peux effectivement faire la même chose avec android-repo. Il me paraît aussi offrir plus de fonctionnalités que mon script, ce qui se fait probablement au détriment de la simplicité.

      PS: Ce n'est même pas du ncurses. Pur texte, 100% fait main. Pas de dépendances, rien.

      • [^] # Re: repo

        Posté par  . Évalué à 3.

        OK, je comprends mieux. Cela dit, tu as quand même eu les bonnes idées (solution au dessus de git, fichier de config pouvant etre committé) qui sont les points forts de repo, donc chapeau ;-)

        Juste pour continuer sur repo, repo a été concu pour accompagner le developpement d'Android, mais il n'est pas lié. On peut tout a fait s'en servir en dehors.

        Pour gerer plusieurs repo git, au debut il y avait les sous modules git qui permettait d'inclure un repo git dans un autre. C'etait pas une mauvaise idée, mais une peu usine a gaz. Les sous modules ont rapidement été dépréciés par les mainteneurs du projet.

        Ensuite Google est arrivé, et a proposé une solution au dessus de git permettant de gerer plusieurs repo ensemble. A l'utilisation, c'est assez simple, plutot bien fait. Le seul truc déroutant est que (par défaut ?), lorsqu'on clone un repository, repo fait un checkout du commit, même si c'est une branche qui est indiquée dans le manifest. Ce qui fait qu'on se retrouve en detached head dès le début, c'est assez moyen pour des utilisateurs basiques de git, obligeant a passer par un "repo start branch_name" avant de commencer a travailler.

        • [^] # Re: repo

          Posté par  . Évalué à 1.

          Pour me petite graine, perso, j'utilise toujours les sous-modules git pour des projets Yocto, la ou beaucoup utilisent "repo".

          Je n'ai toujours pas trouvé l'avantage de repo sur submodule, a par un autre outils a installer et maîtriser en plus de Git…

          Pour le défaut de repo vis a vis des branches, c'est le même problème sous git submodule…
          Dommage…

          • [^] # Re: repo

            Posté par  . Évalué à 2.

            Repo est une surcouche à git, qui a eu le mérite d’exister avant les submodules… (enfin il me semble).

        • [^] # Re: repo

          Posté par  . Évalué à 2.

          OK, je comprends mieux. Cela dit, tu as quand même eu les bonnes idées (solution au dessus de git, fichier de config pouvant etre committé) qui sont les points forts de repo, donc chapeau ;-)

          Repo a été fait pour gérer les sous modules, ce qui n’est pas le cas ici. Ici le but est juste d’avoir une meta gestion de tous les dépôts sur lesquels tu travailles.

    • [^] # Re: repo

      Posté par  . Évalué à 6.

      C'est pas une interface ncurse, c'est son shell.

  • # What's in a name?

    Posté par  . Évalué à 6.

    Pourquoi l'avoir appelé Google Web Service ?

    --->[] Déjà parti très loin :-)

  • # Grammaire

    Posté par  . Évalué à 1.

    Il y a une petite faute : c'est "already exists" avec un s à la fin.

    Sinon bonne idée, j'ai moi aussi un dossier ~/code…

    • [^] # Re: Grammaire

      Posté par  . Évalué à 2.

      Mon point faible, oublier ces ****** de s à la troisième personne. Merci je corrigerai ça pour la prochaine release.

      • [^] # Re: Grammaire

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

        Mon point faible, oublier ces ****** de s à la troisième personne. Merci je corrigerai ça pour la prochaine release.

        Heu, c'est loin d'être le seul problème dans le README! :-) Comme c'est court et que je suis content, je te l'ai reécrit viteuf et j'ai fait un PR. :)

        • [^] # Re: Grammaire

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

          Au temps pour moi, ce n'est pas ton repo! :-S Mais il y a quand-même pas mal de problèmes dans ton texte en anglais — qui a le mérite d'exister.

          Liste, pas exhaustive:

          • Show me pictures

          • for you*r* distribution

          • It reveals which repositories are clean, which one*s* have uncommited changes, or even to know which one*s* are not up-to-date with origin. (Je pense que tu voulais dire origin.)

          • Let's say

          • Then you*r* workspace

          • who use*s* heavily git

          • For instance my current organisation is

          • [^] # Re: Grammaire

            Posté par  . Évalué à 2.

            Liste, pas exhaustive:

            Cool merci, je les ai ajoutées dans l'issue #3, je les corrigerai pour la future release.

        • [^] # Re: Grammaire

          Posté par  . Évalué à 1.

          Heu, c'est loin d'être le seul problème dans le README! :-) Comme c'est court et que je suis content, je te l'ai reécrit viteuf et j'ai fait un PR. :)

          Oui ce n'est de loin pas mon seul point faible (même que ce n'était pas mon repo ;-)), mais c'est LA faute que je fais à tous le coups, d'où mon point faible.

  • # Sympa

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

    J'avais bricolé un outil similaire supportant Git et Mercurial mais lié à RhodeCode/Kallithea.
    L'outil (écrit en Python avec méthode LA RACHE) récupère la liste des dépôts auxquels on a droit via JSON-RPC sur RhodeCode/Kallithea, puis s'occupe de les synchroniser en local avec la même organisation en créant les répertoires qui vont bien avant d'y cloner les dépôts.
    Au lancement le script se met à jour de lui même (pull sur son propre dépôt) puis se relance pour faire le reste, tout en vérifiant l'état des dépôts déjà en place, la sortie donne quelque chose comme :

    Check script updates...
PULL+UP  checker
MAKEDIRS path/to
SKIP     temp/TEST
CLONE    path/to/TRUC
WARNING  clients/TRUC (changesets not pushed)
WARNING  outils/TOTO (non-committed changes detected)
LOCAL    test

    • [^] # Re: Sympa

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

      ça peut m'intéresser, on peut voir le code ?

      ウィズコロナ

      • [^] # Re: Sympa

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

        Hélas, c'est sur un dépôt interne à l'entreprise où je travaille. C'est du multiprocess en Python, et le support de Git n'est pas aussi complet que pour Mercurial (notamment en ce qui concerne hg ingoing et hg outgoing).

  • # Liquidprompt

    Posté par  (Mastodon) . Évalué à 4.

    Dans un autre registre (ce n'est pas de la gestion multi repos) un outil très utile au quotidien quand on travaille sous GIT, c'est liquidprompt.

    Dans le prompt, on a l'état du repo GIT courant : nom de la branche courante, fichiers non encore comités etc. Très très très utile.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Liquidprompt

      Posté par  . Évalué à 6. Dernière modification le 22 février 2015 à 11:44.

      En plus puissant et mieux gaulé tu as: https://github.com/powerline/powerline (enfin sauf si on préfère 2000 lignes de shell qui piquent les yeux à un truc qui a un design propre)

      • [^] # Re: Liquidprompt

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

        powerline est vraiment extra.
        Et pour les utilisateurs de Mercurial qui veulent personnaliser leur PS, il y a hg-prompt de Steve Losh. C'est une extension à Hg qui introduit une nouvelle commande qui prend en argument notre template. Tiré de la doc :

        hg_ps1() {
    hg prompt "{ on {branch}}{ at {bookmark}}{status}" 2> /dev/null
}

export PS1='\u at \h in \w$(hg_ps1)\n$ '

        http://sjl.bitbucket.org/hg-prompt/quickstart/

    • [^] # Re: Liquidprompt

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

      Si c'est juste pour avoir l'état des repositories git, subversion, mercurial, darcs…, pas besoin d'installer quoi que ce soit, vcs_info est déjà là.

  • # myrepo

    Posté par  . Évalué à 3.

    Il y a aussi l'outil mr par l'excellent et incontournable Joey Hess : http://myrepos.branchable.com/

    Visiblement, ça gère même tous les types de repo de manière tout à fait transparente.

    • [^] # Re: myrepo

      Posté par  . Évalué à 2.

      Effectivement ça semble plus ou moins faire le même boulot. Je ne connaissais pas, merci. Il lui manque peut-être juste la notion d'ignore-list pour ne pas manipuler les projets du boulot sur l'ordinateur de la maison, mais sinon il gère bien plus de fonctionnalités.

      Je m'inspirerai de quelques unes de ses idées pour l’hypothétique suite de mon projet dans un langage maintenable ;-)

    • [^] # Re: myrepo

      Posté par  . Évalué à 1.

      mr avec vcsh c'est juste super pratique ! :)

      • [^] # Re: myrepo

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

        Est-ce que ces outils fonctionnent sous windows, dans cygwin par exemple ?

        "La première sécurité est la liberté"

  • # L’utiliser en tant que sous commande git.

    Posté par  . Évalué à 5.

    Pour l’utiliser comme suit :

    $ git gws
…
$

    Il faut juste renomer gws en git-gws.

    • [^] # Re: L’utiliser en tant que sous commande git.

      Posté par  . Évalué à 1.

      Oui je sais que c'est possible, mais je n'y ai pas encore vu l'utilité, à part ajouter 4 caractères à taper en plus chaque fois? Manquerais-je quelque chose?

      • [^] # Re: L’utiliser en tant que sous commande git.

        Posté par  . Évalué à 1.

        Pour que l'utilisateur comprenne bien et vite que c'est une commande relative à l'outil Git.

        Après, rien ne t'empêche aliaser "git gws/git ws/git workspace" en "gws" de ton côté. Un indice : "git workspace" est sans doute la meilleur des trois propositions et éviter les alias barbares permet de « parler » une langue commune :)

        Félicitation pour ton outil.

        • [^] # Re: L’utiliser en tant que sous commande git.

          Posté par  . Évalué à 1.

          Pour que l'utilisateur comprenne bien et vite que c'est une commande relative à l'outil Git.

          Vu comme ça effectivement ça peut faire sens de le lier à git.

          Après, rien ne t'empêche aliaser "git gws/git ws/git workspace" en "gws" de ton côté. Un indice : "git workspace" est sans doute la meilleur des trois propositions et éviter les alias barbares permet de « parler » une langue commune :)

          J'adhère également sur le fait que "git workspace" serait le meilleur choix. Après il semble que cela soit déjà utilisé. "git ws" existe déjà également. Au passage il y a également "git slave" qui semble faire plus ou moins la même chose.

          Si effectivement je fais un nouvel outil, son but sera de s'interfacer avec git/mercurial/darcs/etc. donc la question ne se posera pas vue que ça ne sera pas particulièrement lié à git. Pour ce programme-ci je ne pense pas changer le nom de l'exécutable, vu que quelques personnes l'utilisent déjà et que les noms "ws" et "workspace" de git sont déjà utilisés. Ce que je peux éventuellement faire c'est indiquer dans le README son utilisation via git en renommant ou liant l'exécutable. Je vais quand-même encore y réfléchir.

          Félicitation pour ton outil.

          Merci.

  • # et Peru ?

    Posté par  . Évalué à 1.

    Dans ton fichier de conf d'exemple, tu inclus Peru. J'ai l'impression qu'il a le même but. Peux-tu expliquer les différences ?

    (https://github.com/buildinspace/peru)

    • [^] # Re: et Peru ?

      Posté par  . Évalué à 1.

      Le but de peru n'est pas le monitoring d'un workspace, mais d'offrir «un outil pour inclure le code d'autres personnes dans vos projets».

      Du coup il n'a pas de fonctionnalité pour suivre l'état des repos, ni de visionner l'état des branches. Il est possible de l'utiliser plus ou moins dans le même but, mais il n'est pas forcément pratique pour ça.

  • # Un peu comme mr ?

    Posté par  . Évalué à 2.

    Je n'utilise pas, mais ça ressemble beaucoup à mr : http://myrepos.branchable.com/

  • # scm.py et apply_patch.py

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

    Salut, c'est marrant, j'ai codé la même chose :-) J'ai commencé à écrire scm.py il y a 2 ou 3 ans quand je devais cloner puis mettre à jour une dizaine de dépôts Mercurial au boulot. Ensuite, j'ai ajouté le support de Git car je ne me souvenais jamais si tel projet utilisait git ou mercurial, là j'ai une CLI unifiée pour les commandes les plus courantes. Petit à petit, j'ai ajouté une vingtaine de commandes pour mes besoins :

    https://bitbucket.org/haypo/misc/src/tip/bin/scm.py

    Comme ça m'est arrivé plusieurs fois de perdre des modifications locales avec git et mercurial, scm.py commence par sauvegarder puis annuler les modifications locales avant les opérations qui modifient le dépôt. Du coup, je ne perds plus jamais mes modifications locales. Si réappliquer les modifications échouent, pas grave, je les ai dans un fichier (.hg/stash, .git/stash) sous forme d'un patch.

    J'ai aussi ajouté des avertissements là où git supprime sans crier gare.

    Quelques exemples :

    • scm.py pull : mettre à jour une vingtaine de dépôt git. continue en cas d'erreur : liste les erreurs à la fin. => à utiliser avant de prendre le train/avion sans internet ;-)
    • scm.py clean : supprime tous les fichiers .pyc, .orig, .swp, etc. récursivement dans les sous-dossiers
    • scm.py grep PATTERN : c'est tout con, recherche dans tous les fichiers suivi par git/hg (je n'ai jamais compris à quoi sert à la commande "hg grep" :-)), évite de taper "grep PATTERN $(find . -name *.py|grep -v test)" par exemple (d'autres outils comme ack le font, mais je n'installe jamais ack)
    • scm.py revert : supprime toutes les modifications locales et revient à un état normal (rebase en cours, merge en cours, etc. => hop, annulé)

    Bien sûr, scm.py pull et scm.py push utilisent rebase pour garder un historique linéaire !

    --

    Au passage, j'ai écrit un petit outil par dessus la commande patch : apply_patch.py. C'est tout con : ça devine le paramètre -p pour éviter de mal appliquer un patch, et ça évite évite d'appliquer un patch s'il y a des erreurs (demande confirmation dans ce cas). Ca évite de pourrir un dépôt avec plein de fichiers .bak, .rej, .orig, etc. Je crois que apply_patch.py ne fonctionne pas sous FreeBSD qui malheureusement ne gère pas patch --dry-run.

    https://bitbucket.org/haypo/misc/src/tip/bin/apply_patch.py

    PS : j'utilise aussi scm.py sous Windows où le shell est plutôt pauvre… (Comment on tape find -name ".orig" -o -name ".rej" -delete sous Windows ? :-p scm.py clean)

    --

    Ouais, y'a des outils "similaires". Similaires, donc différents. J'ai vraiment "implémenté" ma manière de manipuler le code dans scm.py, donc il me convient parfaitement :-) Et puis je passe peu de temps à le maintenir (qq. heures par mois max). Le plus pénible récemment était de gérer Python 2 et Python 3, ça devraient maintenant être bon ;-) (Ne gérer que l'un ou l'autre n'est pas pratique dans un virtualenv où "python" peut être l'un ou l'autre).

    • [^] # Re: scm.py et apply_patch.py

      Posté par  . Évalué à 2.

      Salut,

      Oui il y a déjà pleins d'autres gens qui ont listé des projets similaires, il semble y avoir du besoin dans ce domaine :-)

      Concernant ton projet, il a effectivement l'air d'être une implémentation de ta manière précise de travailler. Il ne me conviendrai pas je pense. Malgré cela je m'inspirerai de quelques-unes de tes idées — dans l'hypothétique cas où j'écrirai un nouvel outil. Par exemple le fait d'afficher les erreurs à la fin, ou d'utiliser le stash comme sécurité pour des opérations qui modifieraient les repos.

      Merci pour la présentation de ton outil!

    • [^] # Re: scm.py et apply_patch.py

      Posté par  . Évalué à 2.

      Très intéressant. Manque plus que voir cette description dans le dépôt, d'avoir un dépôt propre au script et on peut partager avec le monde !

  • # Grammaire

    Posté par  . Évalué à 1. Dernière modification le 03 mars 2015 à 18:28.

    Comme tu es perfectionniste, je propose de corriger "Already exist" par "Already exist*s*". La 3ème personne du singulier est la seule qui s'accorde en anglais, je suis sûr que tes profs d'anglais n'ont cessé de te le rabâcher ;)

    EDIT : présentation claire et concise, outil propre et bien pensé, bravo l'artiste.

    • [^] # Re: Grammaire

      Posté par  . Évalué à 2.

      Oui, et je passe mes journées a revérifier mes textes pour rajouter les "s" manquants. Quand ça ne veut pas rentrer, ça ne veut pas…

      Sinon la question des fautes d'orthographe a déjà été discutée là et là. Cela sera corrigé dans la prochaine version, la 0.1.6.

      Merci pour la notification orthographique ainsi que pour l'encouragement!

Suivre le flux des commentaires

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