GitHub para .vimrc e plugins


21

Sei que muitas pessoas armazenam seu .vimrc no GitHub para facilitar o trabalho em novas máquinas, e isso faz todo o sentido para mim. Incluir plugins, no entanto, é problemático, porque os plugins que eu uso já são repositórios git. Como se cria um repo que rastreia o .vimrc e os plugins que possam estar instalados?


Eu sinto que isso pode ser muito orientado para a opinião; não há objetivo "melhor" e há muitas boas opções, cada uma com seus próprios prós e contras. Além disso, o pouco específico sobre repositórios aninhados traz a questão mais para a categoria "using git" e menos para o vim. Talvez se você se concentrou em um problema específico que você teve com os plugins vim ou vim enquanto tentava armazenar sua configuração no github?

3
Eu posso editá-lo para tirar o melhor, se quiser; minha intenção era perguntar mais como "como faço isso?" pergunta, embora reconheça que a maneira como eu estava pensando sobre o problema pode não ser o ideal.
Tom

Isso pode ajudar, mas pode apenas torná-lo uma questão de "lista de coisas" (há, novamente, várias maneiras diferentes de fazer isso de maneira eficaz). Atualmente, existe um tópico sobre meta sobre essas questões, se você quiser contribuir com a discussão sobre como devemos tratar esse tipo de pergunta.

2
Editado. Espero ter deixado mais claro que estou perguntando "como faço isso?"
Tom

1
Basta usar um gerenciador de plugins como o neobundle.
Philip

Respostas:


18

Como lidar com repositórios dentro de repositórios tem sido uma questão constante no git. Os submódulos do Git são uma maneira de lidar com a situação, às custas de adicionar um pouco mais de complexidade para acompanhar. O site git tem uma introdução aos submódulos .

A idéia básica é manter uma referência a outro repositório git associado a um caminho no seu repositório. Essas referências são armazenadas em um arquivo .gitmodulesna raiz do seu repositório (que é gerenciado pelo git, então deixe em paz). Parte da complexidade entra em cena ao clonar um repositório que possui submódulos: você deve git submodule initcriar explicitamente o .gitmodulesarquivo e, em seguida, git submodule updateclonar os submódulos.


Aqui está uma explicação de como vou adicionar um novo plug-in vim ao meu repositório dotfiles (eu tenho o ~/.vim/alias deste repositório .vim/) usando um submodulo:

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

Após o submodule add, a git statusmostraria que você modificou (ou criou) o .gitmodulesarquivo, com algo como isto:

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

Também deve aparecer .vim/bundle/vim-elixircomo um novo arquivo. O Git trata esse caminho especialmente agora: é um diretório normal no seu sistema de arquivos (então o vim o carrega normalmente), mas git diffo tratará como um commit específico em seu repositório. Ao olhar para diffs ou logs para esse caminho (por exemplo git log -1 -u .vim/bundle/vim-elixir), o git mostrará como uma string de uma linha como esta:

Subproject commit 2d59d1d52a9bcf9342d42fa7d6b59e6a1aaa7b9e

A atualização para a versão mais recente dos corresponde plug-in para entrar em repositório do sub-módulo e check-out um novo commit, e depois cometer que ao seu repositório:

$ 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

Obrigado, isso parece exatamente o tipo de coisa que eu estava procurando!
Tom

Ah, eu não percebi que sua resposta foi postada, já que eu estava editando a minha há algum tempo.
muru

23

Você não precisa armazenar plugins no seu VCS; você também pode usar um gerenciador de pacotes Vim. Desde ontem, eu uso o vim-plug :

Você pode definir plugins no seu vimrc da seguinte forma:

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

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

call plug#end()

Em seguida, reinicie o Vim e instale plugins com:

:PlugInstall

Ou você pode adicionar esse trecho da FAQ ao seu arquivo vimrc antes da plug#begin()chamada:

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

Isso colocará os plugins ~/.vim/plugged. Você não precisa manter este arquivo no seu VCS . Se você deseja usar este vimrc em outra máquina, basta ligar :PlugInstallpara essa máquina.

Para remover um plug-in, remova-o do arquivo vimrc e execute:

:PlugClean

Observe que o vim-plug não suporta a instalação de scripts no site de scripts do Vim, mas esses scripts são espelhados no GitHub , portanto não há necessidade de fazê-lo.

Existem também algumas vantagens adicionais, como atualização mais fácil do plug-in e carregamento sob demanda para obter melhor desempenho. Você também não corre o risco de violar os termos de licença dos plug-ins que está distribuindo com seus arquivos vimrc.

Veja também:


5

Eu armazeno meu vimrc no github e os plugins como sub-módulos do meu repositório.

No arquivo readme.md, coloquei um liner que puxa o repositório e executa o script de instalação, desta forma, posso copiar uma linha em um editor e configurar tudo. Faz um pouco mais do que apenas o vim (mas não muito).

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

Para usá-lo:

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. Dispostos a seguir qualquer conselho (como fiz isso há muito tempo e não o tocamos desde então).

Nota: Minha parte favorita é que ele também configura o git e o usa para vim como a ferramenta diff do git. Vimdiff é a melhor ferramenta de comparação.


5

Se você gostaria de ficar com o Pathogen, uma maneira poderia ser usar os submódulos do Git . Quando você adiciona um submódulo, o git o reconhece como de outro repositório e deixa seu conteúdo em paz (a menos que tenha sido alterado, nesse caso, ele aparecerá com conteúdo não rastreado quando você o fizer git status). Se todos os seus plugins baseados no Github estiverem ativados bundle/, adicioná-los como submódulos é uma tarefa bastante simples e com um bom shell:

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

Você pode ver como os submódulos aparecem no meu repositório vimrc .


Se você adicionar um arquivo a um submódulo ou fizer algumas alterações que não afetem o repositório, git statusainda reclamará que o submódulo tenha alterações não confirmadas ou arquivos não rastreados. Você pode fazer o git ignorar essas alterações adicionando ignore = dirtyà configuração do submódulo no .gitmodulesarquivo. Por exemplo:

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

Um benefício dos submódulos é que a revisão do submódulo é adicionada ao repositório git, para que um git initautomaticamente cuide de verificar essa revisão específica. Você pode jogar isso fora e dizer ao git para ignorar os submódulos depois de adicioná-los, adicionando ignore = allsua configuração no .gitmodulesarquivo. Por exemplo:

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

Por fim, um comando para atualizar todos eles!

git submodule foreach git pull

Palavra de cautela: sou novo nos submódulos. Não tenho muita certeza de como eles se comportam.


O vim-pandemia é outra maneira de aprimorar o Pathogen sem a necessidade de usar submódulos. A pandemia lida com os repositórios remotos, deixando o Pathogen para lidar com o runtimepath. Isso significa que precisamos de duas ferramentas, mas para tarefas díspares que "deveriam" ser tratadas separadamente.
jalanb

Alguém pode comentar por que o tpope no readme de patógenos pode dizer por que os submódulos não são o caminho a seguir? Também não conheço submódulos (e minha solução funciona muito bem para mim mesmo sem um gerenciador de plugins), mas acho que a multidão de antimódulos tem algo interessante a dizer.
dash-tom-bang

1
@ dash-tom-bang Eu não leio nem um pouco como ele dizendo que você não deveria usar submódulos. Acho que ele está apenas dizendo que não é o método preferido dele .
Rich Rich

1
TBH depois de alguns anos de uso, fiquei irritado com os submódulos. Eu recomendaria agora não usá-los. Agora uso o vim-plug e isso facilitou minha vida.
Muru

4

Você pode simplesmente adicionar esta linha ao seu .gitignorepara ignorar todos os seus plugins e não comprometê-los:

vim/bundle

Além disso, você disse que é problemático incluir o código do plug-in porque eles já são repositórios do github. Eu acho que você quer dizer que não deseja duplicar o código, mas ouvi dizer que você deve seguir em frente e duplicar o código que é uma dependência, para que você possa sempre voltar a um ponto específico do seu código e saber que vai funcionar. Aqui estão alguns artigos de James Shore que falam sobre isso: http://www.letscodejavascript.com/v3/blog/2014/12/the_reliable_build , http://www.letscodejavascript.com/v3/blog/2014/03/ the_npm_debacle . Ele está falando sobre código de programação e npm (em oposição ao vim), mas acho que o argumento ainda se aplica: você deseja um ambiente confiável para codificar ou escrever.


1
"Você pode apenas adicionar esta linha ao seu .vimrc ..." você quis dizer .gitignore?
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.