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

Posté par StreakyCobra le 26 juillet 2015 à 16:08. Édité par Benoît Sibaud, BAud, palm123, Nils Ratusznik et Ontologia. Modéré par Benoît Sibaud. Licence CC By‑SA.

Étiquettes :

juil.

2015

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?

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 |

Lancez gws update qui va cloner tous les dépôts manquants :
Hackez un peu !
Lancez gws pour voir l'état de votre espace de travail (dépôts, branches) en un clin d’œil :
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.
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: YOLO¹.

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. ↩

Aller plus loin

Journal à l'origine de la dépêche (285 clics)
Projet sur Github (497 clics)
Version empaquetée dans Arch Linux (132 clics)

# Tu vas encore le regretter...

Posté par Olivier LEMAIRE (site web personnel) le 26 juillet 2015 à 17:09. É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

Les logiciels de traitement de texte sont à la rédaction ce que la 2CV est à l'automobile, une vieille voiture dont on se souvient avec nostalgie mais technologiquement dépassée
- [^] # Re: Tu vas encore le regretter...
  
  Posté par StreakyCobra le 26 juillet 2015 à 19:42. É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 Frédéric-Emmanuel Picca le 26 juillet 2015 à 18:29. Évalué à 1.

Tout est dans le titre.

sinon c'est quoi le terminal ?
- [^] # Re: Il est temps de te mettre a haskell
  
  Posté par StreakyCobra le 26 juillet 2015 à 20:32. É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 Victor STINNER (site web personnel) le 28 juillet 2015 à 01:45. É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 moules le 26 juillet 2015 à 18:52. É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 StreakyCobra le 26 juillet 2015 à 19:57. É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 scls19fr (site web personnel) le 27 juillet 2015 à 10:53. Évalué à 1. Dernière modification le 27 juillet 2015 à 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 scls19fr (site web personnel) le 27 juillet 2015 à 11:00. Évalué à 1.
      
      oui en fait c'est ma version de Bash qui était osolète
    - [^] # Re: Auto-détection
      
      Posté par scls19fr (site web personnel) le 27 juillet 2015 à 11:02. Évalué à 1. Dernière modification le 27 juillet 2015 à 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 StreakyCobra le 27 juillet 2015 à 11:19. É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 scls19fr (site web personnel) le 27 juillet 2015 à 11:46. Évalué à 1. Dernière modification le 27 juillet 2015 à 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 Benoît Sibaud (site web personnel) le 27 juillet 2015 à 11:50. É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 scls19fr (site web personnel) le 27 juillet 2015 à 11:55. Évalué à 1.
        
        Merci. Comment peut-on éditer ?
        
        [^] # Re: Auto-détection
        
        Posté par Benoît Sibaud (site web personnel) le 27 juillet 2015 à 13:30. Évalué à 4.
        
        L'auteur peut éditer ses commentaires pendant une courte plage de temps (5min). Ensuite il faut être modérateur pour avoir le droit de modifier. Je l'ai déjà fait sur tes commentaires précédents.
        
        [^] # Re: Auto-détection
        
        Posté par StreakyCobra le 27 juillet 2015 à 12:02. É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 bobi32 le 27 juillet 2015 à 09:31. É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/ ;)
- [^] # Re: Petite correction
  
  Posté par StreakyCobra le 27 juillet 2015 à 09:48. Évalué à 1.
  
  Bien vu, merci! (Si un modo veut corriger cela il est le bienvenu :-)
- [^] # Re: Petite correction
  
  Posté par Benoît Sibaud (site web personnel) le 27 juillet 2015 à 09:56. Évalué à 3.
  
  Corrigé, merci.
# Contribution à MyRepos ?

Posté par Maz (site web personnel) le 27 juillet 2015 à 11:31. É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 StreakyCobra le 27 juillet 2015 à 11:57. É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 Nicolas Boulay (site web personnel) le 27 juillet 2015 à 14:07. É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 mikael.vallerie le 27 juillet 2015 à 12:38. Évalué à 1. Dernière modification le 27 juillet 2015 à 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 StreakyCobra le 27 juillet 2015 à 13:32. É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 mikael.vallerie le 27 juillet 2015 à 14:37. Évalué à 1. Dernière modification le 27 juillet 2015 à 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 mikael.vallerie le 27 juillet 2015 à 14:45. É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 kna le 27 juillet 2015 à 15:24. É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 StreakyCobra le 27 juillet 2015 à 15:32. É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 turanga leela le 27 juillet 2015 à 13:33. É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 StreakyCobra le 27 juillet 2015 à 13:56. É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 Tangi Colin le 27 juillet 2015 à 15:20. É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 StreakyCobra le 27 juillet 2015 à 15:49. É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 Tangi Colin le 27 juillet 2015 à 16:12. É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 StreakyCobra le 27 juillet 2015 à 16:45. É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 Tangi Colin le 27 juillet 2015 à 17:10. É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 StreakyCobra le 27 juillet 2015 à 17:37. É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 barmic le 27 juillet 2015 à 16:58. Évalué à 3. Dernière modification le 27 juillet 2015 à 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 StreakyCobra le 27 juillet 2015 à 17:30. É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…
      - [^] # Re: Fonctionnalité manquantes par rapport à android repo
        
        Posté par mothsART le 27 juillet 2015 à 20:16. Évalué à 2.
        
        le choix d'un autre langage permettra également de lancer plusieurs instances de git en parallèle?
        
        [^] # Re: Fonctionnalité manquantes par rapport à android repo
        
        Posté par StreakyCobra le 27 juillet 2015 à 20:21. Évalué à 2.
        
        le choix d'un autre langage permettra également de lancer plusieurs instances de git en parallèle?
        
        Le lancement des commandes en parallèle pour l'instant est plus problématique par rapport à l'affichage des résultats qu'au langage. Mais effectivement c'est une idée d'amélioration intéressante.
# Pléonasme

Posté par kursus_hc le 27 juillet 2015 à 17:48. É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 !
- [^] # Re: Pléonasme
  
  Posté par StreakyCobra le 27 juillet 2015 à 19:00. Évalué à 1.
  
  Oui, effectivement, un pléonasme informatique ;-)
# Autre outil : scm.py

Posté par Victor STINNER (site web personnel) le 28 juillet 2015 à 01:38. É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 benoar le 28 juillet 2015 à 11:06. É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 Awaxx le 30 juillet 2015 à 09:56. Évalué à -4. Dernière modification le 30 juillet 2015 à 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 Awaxx le 30 juillet 2015 à 23:11. É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 Bruno Adele (site web personnel) le 16 août 2015 à 22:26. É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é

Et une capture d'écran détaillé

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