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

Posté par . Édité par Benoît Sibaud, BAud, palm123, Ontologia et Nils Ratusznik. Modéré par Benoît Sibaud. Licence CC by-sa
Tags :
38
26
juil.
2015
Gestion de versions

gws est un outil KISS (script bash, compatible zsh) pour gérer de manière simple un espace de travail composé de plusieurs dépôts 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 répertoire personnel ?
  • 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 git 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 cloner 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 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 configuration 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 aguichage/teasing rien que pour vous :

  • La commande gws est utilisable depuis n'importe quel endroit de l'espace de travail.
  • Vous pouvez créer plusieurs espaces de travail différents, 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 expressions rationnelles certains projets — par exemple les projets du boulot à la maison.

Où je le trouve?

Il est disponible sur Github et empaqueté pour Arch Linux. 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. 

  • # Tu vas encore le regretter...

    Posté par . Évalué à 2.

    Bonjour
    D'abord merci pour cet outil très utile.
    Je dis que tu vas encore le regretter car la dernière fois, tu avais dit que tu ferais les copies d'écran avec un terminal pourri et tu ne l'as pas fait… Tu sais ce qui va se passer…
    Bref, bravo pour cet outil et merci encore.

    Olivier

    - Dans la vie, il faut toujours se fier aux apparences. Quand un homme a un bec de canard, des ailes de canard et des pattes de canards, c’est un canard. C’est vrai aussi pour les petits merdeux.

    • [^] # Re: Tu vas encore le regretter...

      Posté par . Évalué à 2.

      D'abord merci pour cet outil très utile.
      

      Tout le plaisir est pour moi!

      Je dis que tu vas encore le regretter car la dernière fois, tu avais dit que tu ferais les copies d'écran avec un terminal pourri et tu ne l'as pas fait… Tu sais ce qui va se passer…
      

      Je viens de découvrir que le journal a été promu et publié en dépêche, je l'aurais fait sinon. D'ailleurs il y a eu des corrections orthographiques embarrassantes sur les captures d'écran qui ont été corrigées depuis :-)

  • # Il est temps de te mettre a haskell

    Posté par . Évalué à 1.

    Tout est dans le titre.

    sinon c'est quoi le terminal ?

    • [^] # Re: Il est temps de te mettre a haskell

      Posté par . Évalué à 3.

      Il est temps de te mettre a haskell

      Je m'y suis déjà mis, mais pas pour ce projet. En gros voilà pourquoi (grossièrement traduis):

      […]
      Le problème était relativement simple, alors j'ai décidé d'écrire un petit script bash qui lit une simple liste de répertoires, et qui les clone si ils n'existent pas. Et ensuite, commit par commit, le script a grandi pour finalement devenir un utilitaire pour synchroniser, surveiller et contrôler des espaces de travail.
      […]

      Ce n'était pas un projet construit depuis zéro, mais plutôt un projet par accident, d'où bash. Je ne sais pas quelle est l'orientation exacte la remarque, mais si c'est pour la maintenabilité, j'ai déjà pensé à le réécrire dans un autre langage. J'avais d'ailleurs commencé en OCaml, mais ça stagne depuis quelques mois, problème de temps disponible, comme toujours :-(

      sinon c'est quoi le terminal ?

      Réponse dans ce commentaire (voir le journal à l'origine de la dépêche pour tout le fil de commentaires).

      • [^] # Re: Il est temps de te mettre a haskell

        Posté par (page perso) . Évalué à 2.

        Je ne sais pas quelle est l'orientation exacte la remarque, mais si c'est pour la maintenabilité, j'ai déjà pensé à le réécrire dans un autre langage. J'avais d'ailleurs commencé en OCaml, mais ça stagne depuis quelques mois, problème de temps disponible, comme toujours :-(

        Question facilité d'installation, j'aime bien Python car Python est maintenant disponible de base sous Linux et Mac OS X. Pour ma part, quand j'arrive sous un Windows, j'installe directement Python :-) Donc j'ai Python disponible partout, il n'y a pas besoin de compilation et Python fournit beaucoup d'outils "shell" (modules os & shutil notamment).

        Il m'arrive parfois de lancer mon outil scm.py sous Windows, je crois que ça marche :-D Mais mon utilisation est super limitée sous Windows, en général j'utilise directement hg ou git en ligne de commande.

  • # Auto-détection

    Posté par . Évalué à 3.

    Ce qui pourrait être pratique, c'est de ne pas avoir de fichier .projects.gws mais que le script scrute tous les sous-répertoires qui contiennent un dossier .git.

    • [^] # Re: Auto-détection

      Posté par . Évalué à 4.

      La commande init fait exactement cela: elle génère le fichier .project.gws à partir des répertoires existants. Mais cela ne fait pas de sens de se passer de ce fichier pour 2 raisons:

      • Si le script devait chercher dans toute l'arborescence les répertoires contenant un .git à chaque exécution, cela ne serait pas viable en terme de performance. Cela peut prendre plusieurs secondes à plusieurs minutes, notamment lorsqu'il y a beaucoup de projets.

      • Un des intérêts du projet et de pouvoir versionner et répliquer un espace de travail sur différentes machines, et pour cela il faut de toute façon un index des projets.

      PS: J'ai d'ailleurs implémenté un système de cache dans la dernière version pour gagner en performance en n'ayant pas à parser le fichier de configuration à chaque exécution.

      • [^] # Re: Auto-détection

        Posté par (page perso) . Évalué à 1. Dernière modification le 27/07/15 à 11:46.

        J'ai du faire une bêtise…

        $ gws init
        /Users/path/src/gws: line 122: declare: -A: invalid option
        declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
        \e[92mWorkspace file «.projects.gws» created.\e[0m
        • [^] # Re: Auto-détection

          Posté par (page perso) . Évalué à 1.

          oui en fait c'est ma version de Bash qui était osolète

        • [^] # Re: Auto-détection

          Posté par (page perso) . Évalué à 1. Dernière modification le 27/07/15 à 11:47.

          j'ai mis à jour Bash

          $ brew install bash

          mais c'est toujours pas ça

          $ gws
          sed: 1: ".cache.gws": invalid command code .
          sed: 1: ".cache.gws": invalid command code .
          sed: 1: ".cache.gws": invalid command code .
          cut: illegal option -- -
          usage: cut -b list [-n] [file ...]
                 cut -c list [file ...]
                 cut -f list [-s] [-d delim] [file ...]
          cut: illegal option -- -
          usage: cut -b list [-n] [file ...]
                 cut -c list [file ...]
                 cut -f list [-s] [-d delim] [file ...]
          cut: illegal option -- -
          usage: cut -b list [-n] [file ...]
                 cut -c list [file ...]
                 cut -f list [-s] [-d delim] [file ...]
          cut: illegal option -- -

          mauvais OS… changer d'OS ?

          • [^] # Re: Auto-détection

            Posté par . Évalué à 2.

            Ça à l'air de venir d'une différence de version de coreutils.

            Pourrais-tu ouvrir une issue en y mettant:

            • Un brève description
            • Ce log d'erreur
            • La version de ton OS
            • La version de coreutils, ou si non-existant, la version de cut et de sed

            Merci :-)

            • [^] # Re: Auto-détection

              Posté par (page perso) . Évalué à 1. Dernière modification le 27/07/15 à 11:47.

              En fait il n'y a pas qu'un problème de version de Bash (OS = Mac OS X 10… merde je vais me faire tuer ici!!!)

              Le problème c'est sed qui est différent sous Mac et sous Linux

              $ brew install gnu-sed

              semble avoir réglé le problème
              mais peut-être qu'une autre solution est possible

              http://stackoverflow.com/questions/4247068/sed-command-failing-on-mac-but-works-on-linux

              • [^] # Re: Auto-détection

                Posté par (page perso) . Évalué à 4.

                Tu devrais utiliser la syntaxe ```bash pour avoir la coloration syntaxique shell bash quand tu postes des bouts de code ici (cf bas de page quand tu écris ton commentaire)

              • [^] # Re: Auto-détection

                Posté par . Évalué à 1.

                Oui en cherchant un peu plus loin j'ai vu que cela venait de paramètres spécifiques à GNU-sed. Mais je suis étonné que cela marche car j'ai vu qu'il y a aussi cut qui est différent: le script utilise le paramètre --complement qui semble être spécifique à la version GNU.

  • # Petite correction

    Posté par . Évalué à 1.

    Avec la migration d’AUR sous Git, l’URL du dépôt a changé, donc pour ceux que ça intéresse, voici le lien vers le paquet Arch Linux à jour : https://aur4.archlinux.org/packages/gws/ ;)

  • # Contribution à MyRepos ?

    Posté par (page perso) . Évalué à 2.

    Bonjour

    L'outil ressemble pas mal à MyRepos[1]. Je suppose que tu ne le connaissais pas ?
    gws à l'air de mieux présenter ce qui change par contre.

    Par contre, gws ne gère que git. Est-ce que tu penses que tu pourrais contribuer à myrepos pour l'affichage des changements ? C'est un script python.

    [1] http://myrepos.branchable.com/

    • [^] # Re: Contribution à MyRepos ?

      Posté par . Évalué à 1.

      Effectivement au moment de développer mon outil je ne le connaissais pas. Par contre il a déjà été mentionné lors du premier journal.

      L'approche semble un peu différente, dans le sens où myrepos est beaucoup plus complet et semble pouvoir tout faire, y compris adapter les commandes en fonction des répertoires. gws a une approche plus minimaliste, limitée à git, qui se suffit d'un simple listing ligne par ligne des répertoires. Je le vois un peu comme une version légère de myrepos.

      myrepos a plutôt l'air d'être écrit en perl qu'en python, langage que je ne connais pas, donc non je ne peux pas y contribuer. Et je dois dire que je n'ai pas spécialement d’intérêt à le faire, étant donné que je ne le connaît ni ne l'utilise.

      Dans un futur un peu plus lointain, il n'est pas impossible que je développe un autre outil supportant d'autres VCS que git. Mais cela sera dans un langage un peu plus facile à maintenir que bash si je le fais.

    • [^] # Re: Contribution à MyRepos ?

      Posté par . Évalué à 2.

      J'ai essayé myrepos sous windows, mais il ne marche pas (sous cygwin). Je n'ai pas vraiment compris pourquoi.

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

  • # Cool =)

    Posté par . Évalué à 1. Dernière modification le 27/07/15 à 12:40.

    Bon outil qui va définitivement me servir.

    Idées en vrac pour plus tard (j'ai pas creusé le README, c'est peut être déjà possible) :
    - Possibilité de générer le .projects.gws à partir d'un répertoire existant ? Du genre "gws init ." ?
    - Possibilité de se passer carrément du .projects.gws si on souhaite uniquement utiliser le fast-forward ? En utilisant l'idée d'avant, celle-ci devient moins intéressante.
    - Utilisation d'un format pré-existant (YAML ? JSON ? Autre ?) pour le .projects.gws ?

    Même si ça reste du bash, le code a l'air relativement clean. Après je me mets à ta place : ça doit être sacrément pénible à maintenir.

    Question bonus : ça c'est quoi https://github.com/StreakyCobra/hws ?

    PS : merci pour les paquets AUR ;).

    • [^] # Re: Cool =)

      Posté par . Évalué à 1.

      Bon outil qui va définitivement me servir.

      Par soucis d'exhaustivité, il y a aussi myrepos qui a été cité pour le même usage.

      • Possibilité de générer le .projects.gws à partir d'un répertoire existant ? Du genre "gws init ." ?

      Essaie la commande ;-)

      • Possibilité de se passer carrément du .projects.gws si on souhaite uniquement utiliser le fast-forward ? En utilisant l'idée d'avant, celle-ci devient moins intéressante.

      Question déjà posée dans un autre commentaire.

      • Utilisation d'un format pré-existant (YAML ? JSON ? Autre ?) pour le .projects.gws ?

      Le problème de ces formats, c'est leur parsing en bash… les ratios gains/coûts de ces formats ne sont pas intéressants.

      Même si ça reste du bash, le code a l'air relativement clean. Après je me mets à ta place : ça doit être sacrément pénible à maintenir.

      C'est surtout pénible à faire évoluer… et à cause de bash il y a des améliorations bugs qui sont incroyablement complexes à résoudre sans tout réécrire.

      Question bonus : ça c'est quoi https://github.com/StreakyCobra/hws ?

      C'est un début de tentative d'une réimplémentation en OCaml. Mais cela ne fait rien pour l'instant, il y a juste un début d'interface implémenté.

      PS : merci pour les paquets AUR ;)

      Avec plaisir ;-)

      • [^] # Re: Cool =)

        Posté par . Évalué à 1. Dernière modification le 27/07/15 à 14:39.

        Effectivement, j'aurais pu essayer directement la commande, ça aurait épargné la double idée inutile .

        Pour le YAML, sans rajouter de dépendance, je pense que ça peut se faire à grands coups de grep / sed. Mais évidemment, c'est moche. Je proposais ça surtout dans l'optique d'un utilisateur qui écrirait le fichier lui-même. Avec le gws init, c'est carrément pas indispensable de toute façon :).

        Je connaissais pas myrepos. Ca a l'air de supporter pas mal de choses, mais actuellement j'ai pas le temps de comparer.

        • [^] # Re: Cool =)

          Posté par . Évalué à 0.

          myrepos a l'air mort depuis un certain temps quand même…et pour YAML en bash, y'a bien ce truc immonde à base de sed / awk.

          • [^] # Re: Cool =)

            Posté par . Évalué à 1.

            Je n'ai pas testé personnellement, mais pour JSON avec bash, il y a jq qui a l'air intéressant.

            • [^] # Re: Cool =)

              Posté par . Évalué à 2.

              Il semble y avoir plusieurs moyens de le faire effectivement, mais pour l'instant je ne vois pas d'intérêts à en changer. Le format n'est pas compliqué et fait son travail :-)

              Merci pour le lien au passage.

  • # upstream git

    Posté par . Évalué à 1.

    Bonjour et merci à toi pour ce projet qui va me faire gagner un temps monstrueux.

    J'ai quand même une question: gws utilise des sous-commandes qui ont la même "grammaire" que git mais n'utilise pas les mêmes mots clés. Ne serait-ce pas intéressant de pousser ce projet "wrapper de git" directement sur git en upstream ?

    Dans tous les cas merci à toi

    • [^] # Re: upstream git

      Posté par . Évalué à 1.

      Bonjour et merci à toi pour ce projet qui va me faire gagner un temps monstrueux.

      Ça fait toujours plaisir de savoir que son projet peut être utile à quelqu'un d'autre.

      Ne serait-ce pas intéressant de pousser ce projet "wrapper de git" directement sur git en upstream ?

      Intéressant, peut-être. Faisable, difficilement. Le projet n'est pas suffisamment portable pour être inclus dans git (requière bash>4, coreutils dans sa version GNU, etc.). Il n'est sûrement pas suffisamment testé aussi. Toutefois quelqu'un m'avais proposé d'au moins le fournir en tant que sous commande git pour l'utiliser sous la forme:

      $ git gws update
      $ git gws ff

      C'est quelque chose qui peut facilement être fait du côté utilisateur c'est pourquoi je n'y ai pas donné suite pour l'instant – en plus du fait que ça rallonge les commandes à taper ;-)

  • # Fonctionnalité manquantes par rapport à android repo

    Posté par . Évalué à 3.

    Le prochain est intéressant, j'ai l'idée de faire la meme chose qui trotte dans ma tete depuis pas mal de temps a force d'utiliser les manifests repo d'android pour gérer mes workspaces et trouver certaines limitations dans cette outils.

    Le choix de faire du bash est vraiment un bon choix je trouve, pour ce genre d'outil je veux avoir le minimun de dépendances. Par contre pour le choix du format de fichier .gws j'aurai utilisé le fichier INI du gitconfig et utilisé git config pour l'analyser.

    Y a une fonctionnalité présente dans repo qui manque a gws, c'est le cache local, repo crée un .repo qui va contenir les gits en mode "bare metal", ce qui permet de switcher rapidement entre deux version du workspace sans à devoir tout re-télécharger depuis les serveurs distants.

    Deux autres fonctionnalités que j'aimerai voir implémenter (et qui celle la n'est pas dans repo) c'est :
    1 la possibilité de choisir ces options de clone/fetch (je veux clonner certains gits en mode bare-metal, d'autre en mode shallow etc…)
    2 la possibilité de rajouté un post hook, je vais un gws qui va me générer un workspace, qui va ensuite automatiquement m'appeler un script qui est dans mon workspace. C'est vraiment utile pour versionner des installeur sur lequel on a pas la main.7

    En tout cas bravo pour le job. Faudrait que je trouve le temps d'y contribuer un peu.

    • [^] # Re: Fonctionnalité manquantes par rapport à android repo

      Posté par . Évalué à 1.

      Le choix de faire du bash est vraiment un bon choix je trouve

      Oui et non. Pour les dépendances et la portabilité, oui. Pour la maintenabilité et l'extensibilité, clairement non :-)

      Par contre pour le choix du format de fichier .gws j'aurai utilisé le fichier INI du gitconfig et utilisé git config pour l'analyser.

      Il y a eu plusieurs commentaires concernant le format de fichier. C'est un peu du détail, que ce soit le format X ou Y, cela ne change rien… Pour l'instant le format de fichier fonctionne est n'est pas compliqué, donc je reste la dessus tant que je n'ai pas de complications.

      Y a une fonctionnalité présente dans repo qui manque a gws, c'est le cache local, repo crée un .repo qui va contenir les gits en mode "bare metal", ce qui permet de switcher rapidement entre deux version du workspace sans à devoir tout re-télécharger depuis les serveurs distants.

      Je ne suis pas sûr de comprendre la suite du commentaire. repo a un usage différent de gws. repo est fait pour gérer les dépendances d'un projet, alors que gws a uniquement pour but de surveiller et gérer son espace de travail. Je ne vois pas dans quel cas d'utilisation il serait nécessaire de changer entre deux versions d'un workspace, ni de faire des shallow copies… Aussi d'une fois que les projets sont clonés, il y a juste a travailler dessus, il n'y a plus besoin de les ré-télécharger.

      J'ai l'impression que tu voudrais utiliser gws en place de repo pour gérer les dépendances d'un projet, ce qui n'est définitivement pas son but.

      • [^] # Re: Fonctionnalité manquantes par rapport à android repo

        Posté par . Évalué à 1.

        Effectivement je voudrais remplacer repo par gws.
        Je vois pas en quoi ces deux projets sont si différents, dans les deux cas on a un fichier qui référence les gits qu'on utilise dans son espace de travail (un manifest), leur emplacement et leur version (fonctionnalité manquant pour gws à l'instant mais pas très compliqué à rajouter).

        Le besoin de faire des shallow clones c'est des usages avancés, j'ai des gros git avec beaucoup d'historique et vu gagner sur le temps du git clone.

        Changer entre deux version de ton répertoire de travail c'est si tu utilise gws comme repo, passer d'une version à une autre simplement (et en ne présupposant pas qu'entre les deux versions , il a y exactement le meme nombre de git et/ou au même endroit).

        • [^] # Re: Fonctionnalité manquantes par rapport à android repo

          Posté par . Évalué à 3.

          Effectivement je voudrais remplacer repo par gws.
          Je vois pas en quoi ces deux projets sont si différents, dans les deux cas on a un fichier qui référence les gits qu'on utilise dans son espace de travail (un manifest), leur emplacement et leur version (fonctionnalité manquant pour gws à l'instant mais pas très compliqué à rajouter).

          Ils ne sont pas si différents, mais leurs usages diffèrent grandement, ce qui fait justement que tous les petits détails qui rendent-la-vie-facile™ dans gws pour gérer son espace de travail ne servent à rien dans repo, et vis-versa. D'ailleurs à la base j'avais commencé gws pour me passer de git-submodule qui trackait les versions, ce qui posait justement problème dans le cas des projets. Je ne vais donc pas le rajouter ;-)

          Le besoin de faire des shallow clones c'est des usages avancés, j'ai des gros git avec beaucoup d'historique et vu gagner sur le temps du git clone.

          Comme le but c'est de gérer des projets, tu les clones une seule fois lorsque tu prépare ton espace de travail et c'est tout. Après seul des push et des pull sont nécessaires. Les shallow copy sont donc superflues dans ce cas.

          Changer entre deux version de ton répertoire de travail c'est si tu utilise gws comme repo, passer d'une version à une autre simplement (et en ne présupposant pas qu'entre les deux versions , il a y exactement le meme nombre de git et/ou au même endroit).

          Tu as l'air de vouloir faire de gws ce pour quoi il n'a pas été fait pour. Ce n'est clairement pas une orientation que je vais faire prendre à gws, après libre à toi de l'adapter à tes besoins.

          Regarde peut-être du côté de peru qui sera beaucoup plus près de ce que tu veux faire (et plus adapté aussi :-))

          • [^] # Re: Fonctionnalité manquantes par rapport à android repo

            Posté par . Évalué à 1.

            Merci pour le lien vers peru que je ne connaissais pas. Néanmoins il à l'air d'utiliser git submodules, ce dont je ne veux pas. je veux juste un repo avec deux trois options supplémentaire et quand je regarde le code source de repo (python et orienté objet sans aucune doc) bah je me dis que je ferais mieux de partir from scratch avec un script bash pour la "hackabilité" de la chose et le coté zéro dépendance. Après go pourrait être une alternative intéressante aussi.

            Quand je trouverai le temps de coder un peu pour moi, gws sera surement un bonne base de départ.

            • [^] # Re: Fonctionnalité manquantes par rapport à android repo

              Posté par . Évalué à 1.

              Néanmoins il à l'air d'utiliser git submodules

              Si j'ai bien compris non, il garde justement une copie bare-metal des repository dans un dossier de config, et il fait juste des checkout/clone. Enfin à vérifier.

              Quand je trouverai le temps de coder un peu pour moi, gws sera surement un bonne base de départ.

              On a tous ce problème de temps :-) Bonne chance si tu t'y mets. J'ai essayé de faire gws relativement bien structuré et commenté, j'espère que ça t'aidera.

      • [^] # Re: Fonctionnalité manquantes par rapport à android repo

        Posté par . Évalué à 3. Dernière modification le 27/07/15 à 16:59.

        Oui et non. Pour les dépendances et la portabilité, oui. Pour la maintenabilité et l'extensibilité, clairement non :-)

        Sans vouloir troller sur les langages (j'apprécie beaucoup le shell), le go ne serait pas celui qui s'approche le plus de ce que tu souhaite ? Tu a un binaire qui contient tout, tu es portable et tu as des structures de langages plus classiques et plus facile à faire évoluer ?

        Après je dis ça tu peux très bien me répondre « je t'emmerde, j'écris une version en malboge » :)

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

        • [^] # Re: Fonctionnalité manquantes par rapport à android repo

          Posté par . Évalué à 2.

          Oui et non. Pour les dépendances et la portabilité, oui. Pour la maintenabilité et l'extensibilité, clairement non :-)

          Sans vouloir troller sur les langages (j'apprécie beaucoup le shell), le go ne serait pas celui qui s'approche le plus de ce que tu souhaite ? Tu a un binaire qui contient tout, tu es portable et tu as des structures de langages plus classiques et plus facile à faire évoluer ?

          Oui, Go irait certainement, tout comme probablement Rust, C ou C++. Malheureusement je ne suis pas du tout à l'aise ni expérimenté dans ces langages plutôt orientés bas-niveau.

          gws est en Bash à cause du côté "arrivé là par accident", à force d'améliorer un script qui n'était pas un projet à la base.

          Je suis plus à l'aise dans les langages haut-niveau (Python, Java), de script (Python, Bash) et dans les fonctionnels (OCaml, Haskell). Du coup j'envisage – si j'ai le temps un jour – de faire une nouvelle implémentation en OCaml. C'est statiquement et fortement typé, les types sont inférés, c'est compilé en natif, c'est portable.

          Après je dis ça tu peux très bien me répondre « je t'emmerde, j'écris une version en malboge » :)

          Je t'emmerde, j'écris une version en malboge ;-) Faut juste que j'apprenne le langage avant…

  • # Pléonasme

    Posté par . Évalué à 3.

    Vous avez un dossier ~/dev/, ~/code/ ou ~/workspace/ dans votre répertoire personnel ?

    Je suis tatillon mais ça devrait être soit :

    Vous avez un dossier dev/, code/ ou workspace/ dans votre répertoire personnel ?

    Ou

    Vous avez un dossier ~/dev/, ~/code/ ou ~/workspace/  ?

    Sinon merci pour ce projet que je vais aller tester !

  • # Autre outil : scm.py

    Posté par (page perso) . Évalué à 4.

    Salut,

    J'ai écrit un outil scm.py dans un ancien boulot pour pouvoir mettre à jour une dizaine de dépôts Mercurial en une seule commande. Puis j'ai eu besoin de gérer des dépôts Git. Petit à petit, j'ai ajouté plein de commandes pour mes besoins. Je n'ai jamais trop fait de pub car je ne crois pas que ça intéresse beaucoup de monde.

    scm.py semble offrir les même fonctionnalités que gws. Il fonctionne sur Python (2 et 3, au choix).

    C'est une petite surcouche à hg/git pour améliorer un peu la sortie. Par exemple, "scm.py st" ignore de base les fichiers temporaire ".swp" de vim et le fichier "tags" (pour ctags), et adapte la sortie pour le dossier courant (alors que "hg st" affiche toujours le chemin depuis la racine du dépôt). De même, "scm.py grep PATTERN" ne recherche que dans le dossier courant (et les sous-dossiers), pas tout le dépôt.

    Pour limiter la casse en cas de conflit, les opérations qui modifient le dépôt (pull, histedit, …) mettent les modifications locales de côté sous forme d'un patch (commande stash). Ca aide un peu quand y'a plein de conflits.

    J'ai ajouté des petits trucs comme "scm.py remove_untracked" pour supprimer les fichiers que j'ai crée pendant le dev, et que je veux supprimer pour revenir à un dépôt propre. Ou encore "scm.py info" qui affiche l'URL du dépôt. Je préfère cette sortie à aller chercher dans .hg/hgrc ou .git/config.

    En espérant que ça serve…

    PS: Vu que je passe très peu de temps à développer sur ce projet, ça ne m'intéresse pas trop à contribuer à des projets similaires. De plus, j'ai un peu implémenté ma manière de développer (ex: pull utilise --rebase) et je ne cherche pas à l'imposer à d'autres. Je ne me suis jamais pris la peine d'extraire ce script dans un dépôt dédié pour faciliter les contributions.

    • [^] # Re: Autre outil : scm.py

      Posté par . Évalué à 3.

      Par exemple, "scm.py st" ignore de base les fichiers temporaire ".swp" de vim et le fichier "tags" (pour ctags)

      ~/.gitignore :

      *.swp
      /tags
      ~/.gitconfig :

      [core]
      excludesfiles = ~/.gitignore
      > et adapte la sortie pour le dossier courant

      par défaut pour git

      De même, "scm.py grep PATTERN" ne recherche que dans le dossier courant (et les sous-dossiers), pas tout le dépôt.

      par défaut pour git

      J'ai ajouté des petits trucs comme "scm.py remove_untracked" pour supprimer les fichiers que j'ai crée pendant le dev, et que je veux supprimer pour revenir à un dépôt propre.

      git clean -fd

      Ou encore "scm.py info" qui affiche l'URL du dépôt. Je préfère cette sortie à aller chercher dans .hg/hgrc ou .git/config.

      git remote -v

      En fait, ton problème c'est que hg n'est pas aussi bien que git ? :-)

      PS : et markdown fait encore des siennes pour la deuxième citation ci-dessus… franchement, je le trouve nul face à un reST pour les cas un peu difficiles.

  • # Brain washed out!

    Posté par . Évalué à -4. Dernière modification le 30/07/15 à 09:59.

    gift from the sky
    for i in $(ls ~/gitrep); do cd ~/gitrep/$i && echo "pulling into ~/gitrep/$i" && git pull && cd ~/; done
    
  • # Another

    Posté par . Évalué à -2.

    Permet la syncro de vos répertoires git en une ligne… vous pouvez aussi l'utiliser dans une tache cron…

        for i in ~/gitrep/*; do cd "$i" && git pull; [[ $? > 0 ]] && break; done

    Meilleur que la première… celle ci protège votre chaine de caractère contre ce que l'on appel le word splitting; La boucle aussi s'arrêtera si git retourne une erreur…

  • # Un projet similaire

    Posté par (page perso) . Évalué à 3.

    J'ai également conçu un projet similaire développé en Python, il permet d'avoir des informations sur l'ensemble des projets git d'un sous répertoire.

    Voici la capture d'écran simplifié

    Titre de l'image

    Et une capture d'écran détaillé

    Titre de l'image

    Le projet est hébergé sur Github https://github.com/badele/gitcheck

Suivre le flux des commentaires

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