GitHub pour .vimrc et plugins

Je sais que beaucoup de gens stockent leur .vimrc sur GitHub pour faciliter le travail sur de nouvelles machines, et cela me semble parfaitement logique. L'inclusion de plugins, cependant, est problématique, car les plugins que j'utilise sont déjà des référentiels git. Comment créer un dépôt qui suivra à la fois leur .vimrc et tous les plugins qui pourraient être installés?

Comment gérer les référentiels dans les référentiels a été une question en cours avec git. Les sous - modules de Git sont un moyen de résoudre la situation, au détriment de l'ajout d'un peu plus de complexité à suivre. Le site git propose une introduction aux sous-modules .

L'idée de base est de conserver une référence à un autre référentiel git associé à un chemin sur votre référentiel. Ces références sont stockées dans un fichier .gitmodulesà la racine de votre référentiel (qui est géré par git, alors laissez-le tranquille). Une partie de la complexité entre en jeu lors du clonage d'un référentiel qui a des sous-modules: vous devez explicitement git submodule initcréer le .gitmodulesfichier, puis git submodule updatecloner les sous-modules.

Voici une procédure pas à pas sur la façon dont je vais ajouter un nouveau plugin vim à mon référentiel dotfiles (j'ai un ~/.vim/alias pour ce dépôt .vim/) en utilisant un sous-module:

$ cd dotfiles/
$ git submodule add https://github.com/elixir-lang/vim-elixir.git .vim/bundle/vim-elixir

Après le submodule add, un git statusmontrerait que vous avez modifié (ou créé) le .gitmodulesfichier, avec quelque chose comme ceci:

[submodule ".vim/bundle/vim-elixir"]
    path = .vim/bundle/vim-elixir
    url = https://github.com/elixir-lang/vim-elixir.git

Il devrait également apparaître .vim/bundle/vim-elixircomme un nouveau fichier. Git traite ce chemin spécialement maintenant: c'est un répertoire normal sur votre système de fichiers (donc vim le charge normalement), mais git diffle traitera comme un commit spécifique depuis son référentiel. Lorsque vous regardez les différences ou les journaux pour ce chemin (par exemple git log -1 -u .vim/bundle/vim-elixir), git l'affichera comme une chaîne d'une ligne comme ceci:

Subproject commit 2d59d1d52a9bcf9342d42fa7d6b59e6a1aaa7b9e

Mise à jour à la dernière version du plug - in correspond à de entrer dans le dépôt de sous - module et vérifier un commit, puis engageant que dans votre dépôt:

$ cd .vim/bundle/vim-elixir
$ git remote -v            # note: the submodule repo's origin, not my repo's
origin  https://github.com/elixir-lang/vim-elixir.git (fetch)
origin  https://github.com/elixir-lang/vim-elixir.git (push)

$ git pull
# ...

$ cd -     # back to my repository's root
$ git status
# ...
    modified:   .vim/bundle/vim-elixir (new commits)

$ git diff .vim/bundle/vim-elixir
# ...
-Subproject commit 2d59d1d52a9bcf9342d42fa7d6b59e6a1aaa7b9e
+Subproject commit d59784e7afbd0d55c501e40c43b57cbe6f6e04c2

$ git commit -m "update vim-elixir" .vim/bundle/vim-elixir

Vous n'avez pas besoin de stocker les plugins dans votre VCS; vous pouvez également utiliser un gestionnaire de packages Vim. Depuis hier, j'utilise vim-plug :

Vous pouvez définir des plugins dans votre vimrc comme ceci:

call plug#begin('~/.vim/plugged')

Plug 'embear/vim-localvimrc'
Plug 'kchmck/vim-coffee-script'
" ... etc

call plug#end()

Redémarrez ensuite Vim, puis installez les plugins avec:

:PlugInstall

Ou, vous pouvez ajouter cet extrait de la FAQ à votre fichier vimrc avant l' plug#begin()appel:

if empty(glob('~/.vim/autoload/plug.vim'))
  silent !curl -fLo ~/.vim/autoload/plug.vim --create-dirs
    \ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
  autocmd VimEnter * PlugInstall
endif

Cela mettra les plugins dedans ~/.vim/plugged. Vous n'avez pas besoin de conserver ce fichier dans votre VCS . Si vous souhaitez utiliser ce vimrc sur une autre machine, appelez simplement :PlugInstallcette machine.

pour supprimer un plugin, supprimez-le du fichier vimrc et exécutez:

:PlugClean

Notez que vim-plug ne prend pas en charge l'installation de scripts à partir du site Web de scripts Vim, mais ces scripts sont mis en miroir sur GitHub , il n'est donc pas nécessaire de le faire.

Il existe également des avantages supplémentaires à cela, comme une mise à jour plus facile du plugin et un chargement à la demande pour de meilleures performances. Vous ne courez pas non plus le risque de violer les conditions de licence des plugins que vous distribuez avec vos fichiers vimrc.

Voir également:

• Quelle est la différence entre les gestionnaires de packages vim?
• Comment installer un plugin dans vim / vi?

Je stocke mon vimrc dans github et les plugins en tant que sous-modules de mon référentiel.

Dans le fichier readme.md, je mets une ligne qui tire le référentiel puis exécute le script de configuration, de cette façon, je peux copier une ligne dans un éditeur et il configure tout. Il fait un peu plus que vim (mais pas beaucoup).

https://github.com/Loki-Astari/UnixConfig

Pour l'utiliser:

cd
git clone git@github.com:Loki-Astari/UnixConfig.git ~/.config
cd .config
git submodule init
git submodule update
chmod +x init
./init
cd

PS. Prêt à suivre n'importe quel conseil (comme je l'ai fait il y a longtemps et que je n'ai pas touché depuis).

Remarque: Ma partie préférée est qu'elle configure également git et le configure pour utiliser vim comme outil de diff pour git. Vimdiff est le meilleur outil de diff.

Si vous souhaitez vous en tenir à Pathogen, vous pouvez utiliser des sous-modules Git . Lorsque vous ajoutez un sous-module, git le reconnaît comme provenant d'un autre référentiel et laisse son contenu seul (sauf s'il a été modifié, auquel cas, il apparaîtra comme ayant du contenu non suivi lorsque vous le faites git status). Si vous avez tous vos plugins basés sur Github bundle/, les ajouter en tant que sous-modules est une tâche assez simple avec un bon shell:

for f in bundle/*/ 
do 
    git submodule add $(awk '/url =/{print $3}' "$f/.git/config") "$f"
done

Vous pouvez voir comment les sous-modules apparaissent dans mon référentiel vimrc .

Si vous ajoutez un fichier à un sous-module ou apportez des modifications qui n'affectent pas le référentiel, vous vous git statusplaindrez toujours que le sous-module a des modifications non validées ou des fichiers non suivis. Vous pouvez faire git ignorer ces modifications en ajoutant ignore = dirtyà la configuration du sous-module dans le .gitmodulesfichier. Par exemple:

[submodule "bundle/LaTeX-Box"]
    path = bundle/syntastic
    url = https://github.com/scrooloose/syntastic.git
    ignore = dirty

L'un des avantages des sous-modules est que la révision du sous-module est ajoutée au référentiel git, de sorte que git inita s'occupe automatiquement de vérifier cette révision particulière. Vous pouvez jeter cela et dire à git d'ignorer les sous-modules une fois que vous les avez ajoutés en ajoutant ignore = allà leur configuration dans le .gitmodulesfichier. Par exemple:

[submodule "bundle/LaTeX-Box"]
    path = bundle/LaTeX-Box
    url = https://github.com/LaTeX-Box-Team/LaTeX-Box.git
    ignore = all

Enfin, une seule commande pour les mettre à jour tous!

git submodule foreach git pull

Avertissement: je suis nouveau dans les sous-modules. Je ne sais pas vraiment comment ils se comportent.

Vous pouvez simplement ajouter cette ligne à votre .gitignorepour ignorer tous vos plugins et ne pas les valider:

vim/bundle

En outre, vous avez dit qu'il était problématique qu'il inclue le code du plugin car ils sont déjà des dépôts github. Je suppose que vous voulez dire que vous ne voulez pas dupliquer le code, mais j'ai entendu dire que vous devriez continuer et dupliquer le code qui est une dépendance afin que vous puissiez toujours revenir à un point particulier de votre code et savoir que ça va marcher. Voici quelques articles de James Shore qui en parlent: http://www.letscodejavascript.com/v3/blog/2014/12/the_reliable_build , http://www.letscodejavascript.com/v3/blog/2014/03/ the_npm_debacle . Il parle de programmation de code et de npm (par opposition à vim), mais je pense que l'argument s'applique toujours, vous voulez un environnement fiable pour coder ou écrire.