StreakyCobra a écrit 143 commentaires

Jette un coup d'œil à snap-pac qui fait exactement ce que tu recherches, sur Archlinux :-)

Spacemacs me le fait aussi :-)

Oui je l'ai déjà celui-là, c'était le côté multi-couleur que je trouvais sympa!

Zut, un tel outil serait ludique. Merci de l'info.

Quel est l'outil qui t'as permis d'avoir la coloration? Ou est-ce fait à la main?

Il y a donc Bokeh et Bokeh, à ne pas confondre. Même les logo se ressemblent. Heureusement qu'ils ne sont pas dans le même domaine, ça aurait été difficile pour les recherches sinon.

Je n'avais par vraiment cherché plus loin que cette page à vrai dire, mea culpa. Tant mieux si il est maintenu :-) J'en suis un utilisateur heureux et je ne compte pas en changer vu qu'il est, comme déjà dit, mature est stable.

Joli projet, bravo!

J'ai lu ton commentaire sur Korben:

Le but de Fim est de pouvoir gérer un espace de travail.
Et de savoir où on en est dans les modifications que l'on est en train de faire.
Quand on fait plein de truc en même temps, les choses prennent du temps et on en perd le fil.

Personnellement j'utilise Fim pour gérer mes photos et mes vidéos.
Quand j'ai des nouvelles photos, je les poses au bon endroit dans mon répertoire de photos et ensuite je fais "fim ci" depuis le sous répertoire qui contient les nouvelles photos pour enregistrer ce nouvel état. Comme j'aurais fait avec Git.
Comme je fais cela depuis un sous répertoire le commit est super rapide car Fim ne hash que les nouveaux fichiers que j'ai ajouté et il ajoute les nouveaux hash a la liste des anciens.

La commande "fim diff" me permet de savoir quand je le veux (super rapidement même) si quelque-chose à évolué dans mon répertoire de photos.

Je peux repérer et effacer facilement les photos que j'aurais dupliquées ailleurs sur mon disque ou sur d'autre ordi avec la commande "fim rdup". Pour cela il faut juste que je recopie le répertoire .fim sur l'autre ordi. C'est super rapide.

Cela me fait penser à unison que j'utilise pour synchroniser tous mes documents. Malheureusement celui-ci n'est plus activement développé mais comme il est mature cela ne pose pas trop de problème pour l'instant (je l'utilise quotidiennement depuis 2 ans sans aucun soucis). Je vais garder ton projet dans un coin en cas de problème dans le future :-)

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.

Oui, effectivement, un pléonasme informatique ;-)

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.

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…

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 :-))

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.

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.

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 ;-)

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 ;-)

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.

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.

Ç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 :-)

Bien vu, merci! (Si un modo veut corriger cela il est le bienvenu :-)

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

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.

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 :-)

Effectivement, 11 secondes pour cloner gmic-full à la place des 20 minutes précédemment. Toute cette discussion aura au moins été utile sur un point ;-) C'est top merci!