Journal Gérer ses fichiers de config avec git

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
19
16
avr.
2015

Je continue sur ma lancée des trucs qui enlarge my productivity. Aujourd'hui, voyons comment gérer efficacement ses fichiers de config directement avec git.

Comment gérez-vous les fichiers de configs répartis sur vos différentes machines ? Les synchronisez-vous de temps en temps à coup de scp, rsync ou unison ? Peut-être utilisez-vous un outil évolué comme vcsh ? Mais savez-vous que si ce dernier est une surcouche à git dédiée à la gestion des fichiers de configuration, git seul peut faire l'affaire ?

Bien sûr, tout serait simple si tous les logiciels enregistraient leurs fichiers de configuration dans ~/.config, mais ce n'est pas le cas : beaucoup l'enregistrent directement dans le dossier home. Il va donc falloir versionner tout le dossier home. Oui, c'est sale, j'en vois déjà s'agiter derrière leur clavier ! Mais pas de panique, on va commencer par tout ignorer par défaut :

echo '*' > ~/.gitignore

Il faudra donc par la suite ajouter les fichiers avec git add -f. Mais pour commencer, créons notre dépôt, comme un dépôt git normal :

git init --bare <répertoire_dédié>

Une fois le dépôt créé, on va pouvoir le cloner sur chaque machine concernée.

cd # pour revenir dans son home
git init
git remote add origin/master <adresse du dépôt>
# Supprimer/sauvegarder les fichiers potentiellement écrasés avant de pull (.bashrc notamment)
git pull origin/master master

Avant de pouvoir commencer à envoyer des commits au serveur, il faudra encore exécuter la commande suivante, pour indiquer qu'on veut push sur la branche master du dépôt distant :

git push --set-upstream origin/master master

Et, si ce n'est pas déjà défini dans votre .gitconfig, pensez à définir votre nom ainsi que votre adresse mail :

git config --global user.email "toto@perdu.com"
git config --global user.name "Erika Mustermann"

Et voilà, c'est tout ! Vous pouvez à présent gérer vos fichiers de config comme n'importe quel dépôt git, à l'exception près qu'il faut ajouter les fichiers avec git add -f. Très pratique pour effectuer fréquemment des changements et les diffuser sur ses différentes machines ! Et le versionnage vous permettra de retrouver rapidement une modification effectuée, annuler une config qui-casse-tout…
Faites bien attention de n'ajouter que les fichiers de configuration modifiés uniquement par l'utilisateur, et non pas les différents fichiers de cache (n'ajoutez pas votre .emacs.d/ en entier, par exemple). On regrettera d'ailleurs que certains logiciels tels thunderbird/icedove placent les configs utilisateurs et différentes options modifiées en permanence (dernier dossier ouvert, etc.) dans le même fichier, ce qui empêche un versionnage pratique.

Voilà, bonne gestion de vos dizaines de machines !

  • # Versionner tout ${HOME}: moyen...

    Posté par  . Évalué à 10.

    B'soir !

    Au début, je versionnais tout mon ${HOME}. Et puis j'ai fait une bêtise… Le problème de versionner tout ~/, c'est lorsque l'on fait aussi du dévelopement dans un sous-dossier. Par exemple chez moi, tous mes dévs sont dans ~/dev/.

    Et du coup, il devient facile d'exécuter une commande git et que le dépôt ~/ soit utilisé alors qu'on croyait être dans un répertoire de dev ; ou l'inverse. Ou encore utiliser git au lieu de hg ; ou l'inverse.

    Maintenant, mon ~/ n'est plus un dépôt git, mais ~/.home/ l'est. Et tout ce que je veux versionner dans ~/ je le déplace dans ~/.home/ et crée un lien symbolique (il y a un script pour ça).

    Enfin, le dépôt est pushé vers mon serveur. Quand je veux déployer sur une autre machine, je clone le dépôt depuis mon serveur, lance le script qui crée les liens symboliques.

    Il reste un peu de config locale (e.g. les proxys à utiliser si différents, générer les clés ssh, etc…).

    Voilà. C'est pas parfait, ni absolument propre, mais ça fait l'affaire.

    Hop,
    Moi.

    • [^] # Re: Versionner tout ${HOME}: moyen...

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

      Hum, je n'avais jamais vu le risque sous cet angle…
      Pourtant, je fais comme cela depuis plusieurs années, et je n'ai jamais fait d'erreur malheureuse. Suis-je prudent, ou chanceux ?
      Enfin, avec des sauvegardes régulières, rien n'est dramatique :o)

      • [^] # Re: Versionner tout ${HOME}: moyen...

        Posté par  . Évalué à 7.

        Dans mon prompt, j'ai fait en sorte qu'il m'affiche « ✔ » si le dossier courant est directement versioné (ie contient un .git). Sinon, il m'affiche le dossier racine du dépôt git avec la commande suivante :

        (git rev-parse --show-toplevel | sed -e "s-$(pwd)-✔-g" | rev | cut -d / -f 1 | rev) 2>/dev/null
        Si ça peut aider qqun.

        bépo powered

        • [^] # Re: Versionner tout ${HOME}: moyen...

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

          Merci pour l'astuce.

          Voici un exemple d'intégration dans une variable PS1 :

          PS1='\u@\h:\w [Git: $((git rev-parse --show-toplevel | sed -e "s-$(pwd)-✔-g") 2>/dev/null)] '

          J'ai laissé de côté le bout de code qui enlève tout ce qui précède le dernier slash ( je préfère voir le chemin complet ). J'ai aussi enlevé les couleurs et passages à la ligne pour simplifier.

          • [^] # Re: Versionner tout ${HOME}: moyen...

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

            Pour aller plus loin, voici un exemple pour afficher aussi la branche sur laquelle on travaille :

            function gitIsGitRepository()
{
    output=
    gitTopLevel=$(git rev-parse --show-toplevel 2>/dev/null)
    if [[ $gitTopLevel != '' ]]; then
        if [[ $gitTopLevel == $(pwd) ]]; then
            output="✔ (on $(gitCurrentBranch))"
        else
            output="repository on $gitTopLevel"
        fi
        output="[Git $output] "
    fi
    echo "$output";
}
function gitCurrentBranch()
{
    git rev-parse --abbrev-ref HEAD
}

            Cela rend la PS1 plus lisible:

            PS1='\u@\h:\w $(gitIsGitRepository)'

            Résultat :

            • dans le repo racine : [Git ✔ (on development)]
            • dans un sous-dossier : [Git repository on /chemin/repo_racine]
            • ailleurs, rien ne s'affiche

            Il y a sûrement moyen de faire plus beau mais je ne code pas beaucoup en shell script.

            • [^] # Re: Versionner tout ${HOME}: moyen...

              Posté par  . Évalué à 3.

              Bon, puisqu'on s'est mis à parler prompt, voici le mien.

              Au final, ça ressemble à ça (sur un terminal qui n'affiche pas l'unicode, puis sur un terminal qui affiche l'unicode) sur la largeur complète de la ligne du terminal :

              ,---[~/dev/buildroot±master:bee5ff6!×]------------[1.27|42%v]-------[20150417.181043]---
`-[ymorin@there:pts/2|ret=4]----> _

╭───┤~/dev/buildroot±master:bee5ff6!×├────────────┤1.27|42%↓├───────┤20150417.181043├───
╰─┤ymorin@there:pts/2|ret=4├────> _

              Les infos VCS sont affichées pour git, Mercurial et Subversion ; on y trouve: la branche, le changeset, le statut (fichiers modifiés, non-trackés, dans l'index, stash en cours, en fonction du VCS).

              Les diverses infos incluent par exemple le statut de la batterie, le load average, la date courante, le user et le hostname, le tty (ainsi que la session tmux/screen courante), le code de retour de la dernière commande si non nul, etc…

              Il y a différentes couleurs pour chaque partie, avec les infos importantes en rouge (VCS statut, batterie faible, dernier $? non nul … ), en bleu pour CWD, vert foncé pour la branche VCS, orange pour le changeset courant, vert clair pour le username@host, etc … Il y a trois thèmes de couleurs dispos : green, red et mono.

              Notes : le code est pas très beau et la doc pas complètement à jour, désolé, mais ça a évolué pas mal en presque 9 ans …

              Ceci dit, si quelqu'un sait comment connaître la largeur d'un glyphe, je suis preneur…

              Hop,
              Moi.

      • [^] # Re: Versionner tout ${HOME}: moyen...

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

        je n'ai jamais fait d'erreur malheureuse.

        -> chance

        avec des sauvegardes régulières

        -> prudence

        Là où tu serais malchanceux, c'est si tes sauvegardes sont foireuses.

        « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 3.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # Attention, risque sympatique.

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

    Attention au git clean dans le mauvais répertoire, cela fait désordre…

    Histoire vécue. Je fais souvent des git clean (enfin moi c'est du hg purge, mais c'est pareil) pour nettoyer un dépôt de tous les trucs inutiles qui sont arrivés et pan… plus de home…

    Personnellement j'ai une solution avec un sous répertoire de mon home pour les fichiers de config versionnés et je crée automatiquement les liens symboliques qui vont bien.

    • [^] # Re: Attention, risque sympatique.

      Posté par  . Évalué à 2.

      Marrant ça…
      Ça me rappelle vaguement quelque chose… ;-)

    • [^] # Re: Attention, risque sympatique.

      Posté par  . Évalué à 2.

      Bizarre, je viens de lire le man de git clean (connaissais pas, merci) et ça dit :

      Normally, only files unknown to Git are removed, but if the -x option is specified, ignored files are also removed. This can, for example, be useful to remove all build products.

      Du coup si tu a fais un .gitignore avec * dedans et que tu add -f juste ce qu'il faut, comme le monsieur a dit, faire un git clean ne supprime rien puisque tu ne peux pas avoir de fichiers untracked (seulement des fichiers ignored).

      À moins que tu ne fasses régulièrement des git clean -x ?

      • [^] # Re: Attention, risque sympatique.

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

        Ba oui… Globalement c'est surtout les fichiers ignoré que je supprime avec git clean. Les autres j'ai tendance à supprimer à la main car c'est soit des fichier à ajouter, soit des fichiers qui doivent sans doute avoir une raison d'être là ou d'être bougé ailleurs.

      • [^] # Re: Attention, risque sympatique.

        Posté par  . Évalué à 1.

        À moins que tu ne fasses régulièrement des git clean -x ?

        Oui, quand on développe sur des packages pas encore très propres, par exemple. Je fait même assez souvent des git clean -dx pour vraiment tout virer (sous-répertoires compris).

        Hop,
        Moi.

  • # Sous modules

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

    Plutôt que d'utiliser une configuration unique, pourquoi ne pas éclater la configuration en différents sous-modules ?

    Ça permet d'avoir un repo git pour chaque configuration (par exemple vim, i3, bashrc) que l'on peut cloner sur une autre machine de manière indépendante. Je pense qu'il peut être intéressant de ne cloner la configuration que d'une seule application (entre le pc du bureau et le pc à la main par exemple), sans pour autant rapatrier l'ensemble de son home.

    La repo général ne fait que référencer l'ensemble des différentes configuration.

    • [^] # Re: Sous modules

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

      Je préfère avoir un repo général, personnellement. Plus facile à gérer, et ça ne me dérange pas de rapatrier les confs d'applications que je n'utilise pas sur certaines machines.

  • # vcsh myrepos

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

    http://blog.tfnico.com/2014/03/managing-dot-files-with-vcsh-and-myrepos.html

    Cela ma rappelle l'usage de mr et de vcsh pour gérer ses config, mais je n'ai jamais testé.

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

  • # Pour quoi pas Git pour /etc, mais solution au niveau filesystem pour /home

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

    Ça fait un moment que je réfléchis à mettre mon /etc sous Git. Je pense que c'est une bonne idée, mais quelqu'un a-t-il déjà tenté et peut-il témoigner ?

    Par contre pour mon /home, je suis un fan absolu de rsnapshot. Pour ceux qui ne connaissent pas, ça implémente (en mieux) cette page qui a été une illumination pour moi : http://www.mikerubel.org/computers/rsync_snapshots/
    (C'est plus ou moins ce que Apple a appelé la Timemachine).

    On crée autant de snapshot qu'on veut, en les faisant tourner (toutes les 3h, je garde les 4 derniers, ainsi que tous les jours, je garde les 7 derniers, ainsi que toutes les semaines etc…), mais ça ne 'coûte' que une fois la totale (car ça sert d'archive), ainsi que une fois chaque différence (seuls les fichiers qui diffèrent entre les différents snapshots sont dupliqués).

    C'est pas tout à fait le même but que de versionner par git (on perd le concept d'historique, de traçabilité), mais ça suffit à revenir en arrière sur n'importe quel incident.

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

  • # Ma solution

    Posté par  . Évalué à 5.

    J’ai jamais prit le temps de la publier, mais ma solution est un poil plus complexe, elle évite le fait de versionner tout le home (donc les sous dossiers ne se croient pas dans un répertoire git). En fait le dépôt git est dans ~/.sync/ ; et on utilise un alias pour gérer ce dépôt :

    alias gitsync="GIT_DIR=~/.sync/.git git"

    L'installation se passe comme suit :

    git clone maison:~/git/sync ~/.sync; cd ~/.sync; ./.init-sync

    Pour initialiser le tout, le fichier .init-sync va paramétrer l’environnement:

    #!/bin/bash
if [ -d .git -a "$PWD" != "$HOME" ]; then # This is a first run
        # At first run, we're run from the git dir, unconfigured
        export GIT_DIR=$PWD/.git
        git ls-files HEAD . |xargs rm -r
        git config --add core.worktree $HOME
        git checkout -f
        # configure bash
        echo "if [ -f ~/.bash-commons ]; then
    . ~/.bash-commons
fi" >> ~/.bashrc
else
        export GIT_DIR=$HOME/.sync/.git
fi
cd $HOME
git submodule init
git submodule update
#configure vim
vim +BundleInstall +qall

    Pour ajouter des fichiers dans le dépot:

    gitsync add -f .gitconfig

    Et ça permet de tracker et synchroniser à peu près tout ce qui compte (config bash, git, vim, less). Certains paquets supplémentaires sont installés comme submodules (z/autojump, icdiff, vimpager,…).

    Le fichier ~/.init-sync peut être relancé sur quand des nouveaux paquets vundle ou submodules sont ajoutés.

  • # BSD Owl Scripts

    Posté par  (site web personnel) . Évalué à 9. Dernière modification le 17 avril 2015 à 11:09.

    Sommaire

    Comment gérez-vous les fichiers de configs répartis sur vos différentes machines ?

    Je fais ça avec BSD Owl Scripts¹ qui propose un module dédié pour les systèmes FreeBSD.

    Organisation

    Dans mon parc, j'ai quelques ordinateurs personnels sous FreeBSD ou Mac OS X et quelques systèmes virtualisés dans des jails. Chaque machine, possède un dossier contenant ses fichoers de configuration et il existe un dossier common contenant les fichiers communs à toutes les machines:

    % ls
common    creidhne  llea      mongan    poudriere puk

    Tous ces dossiers sont dans un dépôt git qui est cloné sur chaque machine réelle – les machines virtualisées dans des jails n'ont pas besoin du clone, cf. ci-dessous.

    Fichiers communs

    Dans le fichier common on trouve par exemple un fichier host mais aussi plein de petits trucs du style configuration du dæmon npd qui met à jour l'horloge du réseau, ou bien un fichier Xresource.

    % ls common
10-ignore-patterns.fdi hosts                  ports-supfile
PolicyKit.conf         loader.conf            portsnap.conf
Xmodmap                login.conf             refuse-supfile
Xresources             make.conf              resolv.conf
devfs.conf             motd                   src.conf
devfs.rules            networks               stable-supfile
doc-supfile            ntp.conf               sudoers
fonts-local.conf       pkgtools.conf          sysctl.conf

    Fichiers par machine réelle

    Pour la machine réelle llea on a les fichiers spécifiques suivants: on y trouve la configuration de SSH, de NFS, de poudrière, de musicpd, etc.:

    % ls llea
ls
Makefile            exports             loader.conf.local   smartd.conf
NOTES               ezjail.conf         make-site.conf      ssh_config
NOTES.jail          fstab               musicpd.conf        sshd_config
allow-restart.pkla  fstab.creidhne      periodic.conf       sysctl.conf
device.hints        fstab.mongan        poudriere.conf      ttys
dump_hdaa_config.ml jail.conf           rc.conf             xorg.conf

    La partie importante est le Makefile:

    ### Makefile -- The LLEA workstation

BOOT=           loader.conf
BOOT+=          loader.conf.local
BOOT+=          device.hints

BASE=           rc.conf
BASE+=          login.conf
BASE+=          sysctl.conf
BASE+=          fstab
BASE+=          fstab.creidhne
BASE+=          fstab.mongan
BASE+=          ttys
BASE+=          resolv.conf
BASE+=          ntp.conf
BASE+=          devfs.rules
BASE+=          sshd_config
BASE+=          ssh_config
BASE+=          exports

BASE+=          hosts
BASE+=          networks
BASE+=          jail.conf
BASE+=          periodic.conf

XORG=           xorg.conf
XORG+=          Xresources
XORG+=          Xmodmap

PORT=           sudoers
PORT+=          ezjail.conf
PORT+=          musicpd.conf
PORT+=          poudriere.conf

PKLA+=          allow-restart.pkla

.PATH: ../common

.include "conf.freebsd.mk"

### End of file `Makefile'

    Les listes BOOT, BASE, XORG, PORT et PKLA énumèrent respectivement les fichiers de configuration pour le démarrage de la machine, pour le système de base, Xorg, les ports et les règles pour le Policy Kit de FreeDektop.org.

    L'incantation magique .PATH: ../common indique à bmake que les fichiers non trouvés dans le dossier courant peuvent être cherchés dans ../common. Après ceci un petit make install donne

    % console
make install
===> Switching to root credentials for target (install)
Password:
install -d /etc
install -d /etc/ssh
install -d /etc/ssh
install -d /usr/local/etc
install -d /usr/local/etc/polkit-1/localauthority/50-local.d
install -d /boot
install -d /etc/X11
install -o root -g wheel -m 444 rc.conf /etc
install -o root -g wheel -m 444 ../common/login.conf /etc
install -o root -g wheel -m 444 sysctl.conf /etc
install -o root -g wheel -m 444 fstab /etc
install -o root -g wheel -m 444 fstab.creidhne /etc
install -o root -g wheel -m 444 fstab.mongan /etc
install -o root -g wheel -m 444 ttys /etc
install -o root -g wheel -m 444 ../common/resolv.conf /etc
install -o root -g wheel -m 444 ../common/ntp.conf /etc
install -o root -g wheel -m 444 ../common/devfs.rules /etc
install -o root -g wheel -m 444 sshd_config /etc/ssh
install -o root -g wheel -m 444 ssh_config /etc/ssh
install -o root -g wheel -m 444 exports /etc
install -o root -g wheel -m 444 ../common/hosts /etc
install -o root -g wheel -m 444 ../common/networks /etc
install -o root -g wheel -m 444 jail.conf /etc
install -o root -g wheel -m 444 periodic.conf /etc
install -o root -g wheel -m 440 ../common/sudoers /usr/local/etc
install -o root -g wheel -m 444 ezjail.conf /usr/local/etc
install -o root -g wheel -m 444 musicpd.conf /usr/local/etc
install -o root -g wheel -m 444 poudriere.conf /usr/local/etc
install -o root -g wheel -m 444 allow-restart.pkla /usr/local/etc/polkit-1/localauthority/50-local.d
install -o root -g wheel -m 444 ../common/loader.conf /boot
install -o root -g wheel -m 444 loader.conf.local /boot
install -o root -g wheel -m 444 device.hints /boot
install -o root -g wheel -m 444 xorg.conf /etc/X11
install -o root -g wheel -m 444 ../common/Xresources /etc/X11
install -o root -g wheel -m 444 ../common/Xmodmap /etc/X11
cap_mkdb /etc/login.conf

    On voit une authentification avec su - mais on pourrait utiliser sudo aussi. La dernière ligne montre un petit détail sympa puisque la base de donnée des logins est automatiquement reconstruite.

    Fichiers par machine virtualisée dans une jail

    C'est la même chose que pour une machine réelle, mais il faut ajouter une déclaration JAILDIR qui indique la racine du système de fichiers du système virtualisé:

    ### Makefile – The CREIDHNE Trac server

JAILDIR?=   /guest/jail/creidhne
…

    Ainsi dans le système hôte, on peut installer les fichiers dans le système virtualisé:

    % make install
===> Switching to root credentials for target (install)
Password:
install -d /guest/jail/creidhne/usr/local/etc/apache24
install -d /guest/jail/creidhne/usr/local/etc/apache24/Includes
…
install -o www -g www -m 640 site.html /guest/jail/creidhne/var/trac/templates
install -o www -g www -m 640 style.css /guest/jail/creidhne/var/trac/htdocs
…

    Et voilà!

    Prolongations

    Si vous êtes tentés pour avoir la même chose sur votre sytème Linux préféré n'hésitez pas à me faire part de vos besoin sur le issue tracker du projet! Même en français ou en allemand! :)

    ¹ Disponible sous Debian, Ubuntu, et bientôt MacPorts et FreeBSD. Une installation à la mano est possible et facile. Marche aussi sous Cygwin.

  • # seafile

    Posté par  . Évalué à 4.

    J'avais suivi une méthode proche de la tienne, mais il faut penser à pousser et récupérer les versions c'est assez lourd et j'y pense jamais.

    À la place j'utilise une bibliothèque seafile, qui me synchronise un dossier automatiquement et je fais les liens symbolique qui vont bien (ce que je faisais déjà avec git).

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

  • # ~/.config

    Posté par  . Évalué à 1.

    Bien sûr, tout serait simple si tous les logiciels enregistraient leurs fichiers de configuration dans ~/.config, mais ce n'est pas le cas : beaucoup l'enregistrent directement dans le dossier home

    C'est vrai que ça serait bien mieux ! Pourquoi ce n'est que peu respecté ?

    • [^] # Re: ~/.config

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 18 avril 2015 à 17:27.

      Le poids de l'historique.

      • Pour les logiciels écrits avant la norme : il a bien fallu que des dizaines de milliers de logiciels écrivent directement dans ~/.cedontilsontenvie pour que des gens se disent que c'est trop le bordel et que ça serait bien de normaliser. Ils ne la respectent que si quelqu'un met les mains dans le cambouis, forcément, au risque de péter des trucs.
      • Pour les nouveaux : le libriste moyen qui hurle au complot satanocapitaliste quand un gros éditeur ne respecte pas une norme obscure, mais qui va quand même pas se faire chier à faire gaffe quand c'est lui qui code. (ça marche aussi pour les gotofail dont on se gausse chez Apple et ah merde y a les mêmes dans les libs de sécu libres)

      • [^] # Re: ~/.config

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

        Et… malheureusement certains ne mettent pas que de la config là-dedans… mais aussi des données de cache…

        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

  • # git + run-part

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

    Je ne m'y suis mis que récemment, avant je ne copiais que mon .vimrc .

    • J'ai eu une passe avec un .git dans le home mais cela ne ma pas convaincu.
    • J'ai pensé le faire en puppet mais c'était un peu overkill.

    Depuis peut j'ai formalisé ça dans un git qui installe des liens, run-part et des scripts s'occupe de l'installation.

    Du coup cela gère aussi l'installation des packages et des outils de dev.

    pub : https://github.com/simkim/dotfiles

  • # Ma solution à base de GIT_DIR/GIT_WORK_TREE

    Posté par  . Évalué à 3.

    Ma solution c'est une commande séparée qui passe tout à git avec le bon GIT_DIR/GIT_WORK_TREE, car c'est très facile de faire travailler git en dehors d'un dépôt, plutôt que de se prendre la tête à faire des liens symboliques…

    Le dépôt est stocké dans ~/.dotfiles.git, et on appelle la commande dotg pour effectuer ses opérations dessus (les arguments sont comme pour git). Il y a juste deux petites commandes en plus pour initier/cloner son dépôt de configuration.

    C'est vraiment un wrapper léger autour de git, mais avec juste le sucre qu'il faut pour que ça marche de manière robuste et sympatique.

    C'est ici : http://dolka.fr/code/gitweb/?p=dotfiles.git;a=shortlog;h=refs/heads/master
    voire http://dolka.fr/code/gitweb/?p=dotfiles.git;a=blob;f=bin/dotg;h=a651ce2804a64b8e2ef41b883c2c15d0d71b40ee;hb=378c0f6e1c0c0d8d760cc586a700a991a12854f3 pour le code du script en version actuelle directement.

Suivre le flux des commentaires

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