Existem armadilhas para colocar $ HOME no git ao invés de criar um código para os dotfiles?

Question

Eu tenho, por muitos anos, todo o meu diretório $HOME verificado na subversão. Isso incluiu todos os meus perfis de aplicativos e dotfiles, muitos scripts, ferramentas e hacks, minha estrutura de diretórios básicos preferida, não alguns projetos excêntricos e um depósito de dados aleatórios. Isto foi uma coisa boa. Enquanto durou.

Mas ficou fora de controle. O checkout básico é o mesmo em dezenas de sistemas, mas nem todo esse material é apropriado para todas as minhas máquinas. Nem sequer todos funcionam bem com diferentes distros.

Estou no processo de limpeza doméstica - separando os dados de onde eles pertencem, dividindo alguns scripts como projetos separados, corrigindo alguns links quebrados em coisas que devem ser automatizadas, etc.

Minha intenção é substituir subversion por git para o check-out de nível superior de $HOME , mas gostaria de reduzi-lo a apenas as coisas que gostaria de ter em TODOS os meus sistemas, ou seja, dotfiles , alguns diretórios e alguns scripts personalizados básicos.

Ao ler on-line, muitas pessoas parecem estar fazendo isso usando a abordagem do symlink: clone em um subdiretório e crie links simbólicos de $HOME no repositório. Tendo meu $HOME sob Controle de versão completa por mais de uma década, eu não gosto da idéia desta abordagem e não consigo descobrir por que as pessoas parecem tão avessos ao método de checkout direto. Há armadilhas que eu preciso saber sobre o git como um check-out de nível superior para $HOME ?

_{P.S. Em parte como um exercício de boa codificação, também estou planejando tornar público o checkout de raiz no github. É assustador a quantidade de informações confidenciais de segurança que eu consegui coletar em arquivos que poderiam ser compartilhados sem pensar duas vezes! Senha WiFi, chaves RSA não passphrased, etc. Eeek!}

    

Answer 1

Sim , há pelo menos uma grande dificuldade ao considerar git para gerenciar um diretório inicial que não seja uma preocupação com subversion .

O Git é ganancioso e recursivo por padrão .

O Subversion irá ignorar ingenuamente qualquer coisa que ele não saiba e irá parar o processamento das pastas para cima ou para baixo a partir do seu checkout quando ele chegar a um que ele não saiba (ou que pertença a um repositório diferente). O Git, por outro lado, continua recursando em todos os diretórios filhos, tornando as verificações aninhadas muito complicadas devido a problemas de namespace. Como o seu diretório home provavelmente também é o lugar onde você faz o checkout e trabalha com vários outros repositórios git, ter seu diretório home no git quase certamente tornará sua vida uma bagunça impossível.

Como se constata, esta é a principal razão pela qual as pessoas fazem o check-out de seus arquivos de ponto em uma pasta isolada e, em seguida, criam links simbólicos nele. Ele fica fora do caminho ao fazer qualquer outra coisa em qualquer diretório filho do seu $HOME . Embora isso seja puramente uma questão de preferência se você for verificar sua casa como subversão, isso se torna uma questão de necessidade se você usar o git.

No entanto , existe uma solução alternativa. O Git permite algo chamado "raiz falsa", onde toda a maquinaria do repositório está escondida em uma pasta alternativa que pode ser fisicamente separada do diretório de trabalho de checkout. O resultado é que o kit de ferramentas do git não ficará confuso: ele nem mesmo CONSULTARá seu repositório, apenas a cópia de trabalho. Ao definir algumas variáveis de ambiente, você pode avisar o git onde encontrar as mercadorias para os momentos em que estiver gerenciando seu diretório pessoal. Sem as variáveis de ambiente definidas, ninguém é o mais sábio e sua casa parece um arquivo clássico.

Para fazer esse truque fluir um pouco mais suave, existem algumas ótimas ferramentas por aí. A lista de discussão de vcs-casa parece o lugar de defacto para começar, e a página sobre tem um embrulho conveniente de howtos e pessoas experiências. Ao longo do caminho, algumas pequenas ferramentas interessantes como vcsh , mr . Se você quiser manter seu diretório home diretamente no git, o vcsh é quase uma ferramenta indispensável. Se você acabar dividindo seu diretório home em vários repostories nos bastidores, combine vcsh com mr para uma maneira rápida e não muito suja de gerenciar tudo de uma vez.

    

Answer 2

Eu não quero que todo o meu diretório pessoal seja verificado no controle de versão simplesmente porque isso significa que cada subdiretório em que eu entrar teria o contexto de controle de versão do meu diretório inicial. Comandos como git checkout teriam uma ação real nesse caso, causando problemas se eu acidentalmente executasse algo do diretório errado, se algo é git ou um script que chame git.

Também aumenta a probabilidade de adicionar algo ao repositório que você não deseja, o que não teria sido um problema quando você fez check-in, mas agora se torna um problema. E se você acidentalmente adicionar um arquivo de chave privada (talvez por hábito) e enviá-lo ao github?

Dito isto, acho que as principais desvantagens não são realmente técnicas - apenas querer salvar-me de mim mesmo.

Quanto ao symlinking: Você pode clonar seu repositório em um subdiretório e ter um script que atualize quaisquer links simbólicos que precisem ser atualizados. A quantidade de manutenção necessária para esse script pode superar os benefícios de tê-lo, no entanto; o symlinking pode se tornar menos trabalho.

Com links simbólicos, você também pode fazer adições específicas da distribuição (ou até mesmo específicas do host) que são verificadas no git. Seu script symlink-update irá ignorar os arquivos destinados a plataformas incompatíveis ou diferentes hosts, e somente atualizará os apropriados.

Algo como:

HOMEREPO=$HOME/homerepo
HOST=$(hostname)
UNAME=$(uname)

for dotfile in $HOMEREPO/shared/* $HOMEREPO/host-$HOST/* $HOMEREPO/uname-$UNAME/*
do
    target=$HOME/$(basename $dotfile)
    [ ! -r $target ] && ln -s $dotfile $target
done

Pessoalmente: eu uso links simbólicos e não faço links simbólicos para diretórios; apenas os arquivos dentro. Isso me dá alguma flexibilidade para fazer alterações locais no site nesses diretórios (isto é, adicionar / remover arquivos). Configurar minha conta em um novo sistema é entediante porque preciso recriar todos os links simbólicos manualmente.

    

Answer 3

Para dar outro ponto de vista: Eu tenho o meu $ HOME sob o git desde há algum tempo e não encontrei nenhum inconveniente. Eu obviamente não sincronizo este repositório do git com o github; Eu uso um serviço com repositórios privados. Eu também não coloco nenhum arquivo de mídia ou downloads ou pacotes sob controle git.

• git status é uma espécie de lista de verificação "para fazer, limpar".

• Eu tenho um ~/tmp para coisas temporárias, que é gitignored.

• Eu gosto de ver em git status qualquer coisa que um software instalado recentemente ousa adicionar ao meu $ HOME, e geralmente exclui esses arquivos, ou até mesmo desinstala os culpados.

• Eu adiciono manualmente os arquivos e diretórios locais realmente úteis para .gitignore , que tem um benefício "saiba o que você faz ao instalar as coisas".

• Se eu construir uma nova VM ou instalar um novo PC, basta clonar minha casa remota em $ HOME e ter imediatamente tudo que preciso em mãos.

• Coisas como o vundle para plugins vim não são mais necessárias.

Eu não gosto de complexidade. Quando eu ajustar qualquer rcfile, eu apenas faço, comprometo e empurro. Então, como um reflexo, eu pego em $ HOME todos os dias, e tenho sempre a configuração mais recente. É tão simples assim.

Máquinas atualmente sob este regime: laptop doméstico, PC de trabalho, VM de trabalho, mais 3 ou 4 servidores remotos.

    

Answer 4

Já experimentei os dois, e preferi a abordagem de link simbólico no final:

• Confira para onde
• make install
• Efetue logout e novamente para carregar as configurações do X

Desvantagens:

• É preciso mover os arquivos para o repositório antes de adicioná-los
• É necessário manter a lista de links simbólicos no Makefile

Vantagens:

• Não há necessidade de um .gitignore massivo (tenho 133 dotfiles em ~ na minha humilde caixa Ubuntu)
• Pode manter scripts de manutenção e outras coisas relacionadas a ~ (como Makefile e cleanup.sh ) fora do caminho
• A versão pode controlar configurações pessoais e públicas separadamente

Restrições:

• Ao contrário de @mrb, apenas crie links simbólicos em ~ . Isso mantém o symlinking simples e torna trivial notar novos arquivos em, por exemplo, ~/.vim , ao custo de uma manutenção .gitignore muito rara.

Essas duas últimas vantagens derrubaram a balança no meu caso - não quero confundir o diretório pessoal e quero manter o conteúdo privado e público claramente separado.

O único aplicativo que eu sei que tem (ou pelo menos tinha) problemas com o manuseio de links simbólicos era o Pidgin - Ele mantinha sobrescrevendo meus links simbólicos com arquivos comuns.

    

Answer 5

Aqui está um: Se você tentar fazer git rebase -i --root e você tiver feito check em .gitconfig no primeiro commit no repositório, o git removerá temporariamente o arquivo .gitconfig , que por sua vez o impossibilitará de terminar rebase operação desde que requer seu nome e seu e-mail para fazer isso, que são armazenados nesse arquivo.

Você pode configurá-los novamente e fazer git rebase --continue , mas depois que eu fiz isso e finalizei a operação de rebase, meu repositório git ganhou uma confirmação vazia sem uma mensagem de commit antes do commit que era anteriormente o primeiro commit no repositório , que eu não sei como me livrar.

Não sei o que acontece se você usa git rebase -i <commit> , e .gitconfig é verificado junto com qualquer confirmação após <commit> .

Talvez a solução mais fácil seja deixar de adicionar .gitconfig ao repositório e listá-lo em .gitignore .

    

Answer 6

É assim que eu faço:

1. instale um linux limpo (não é necessário, mas torna a vida mais agradável no passo 4)
2. instale o etckeeper
3. execute git init em sua casa
4. crie .gitignore e adicione tudo o que parece que não lhe interessa ou que pode mudar muito. Não se esqueça de adicionar itens como *.cache , *.lock etc. Eu não recomendo adicionar /* porque você não será notificado automaticamente quando algo novo for adicionado à sua casa. É uma abordagem de blacklist versus whitelist approach, onde eu basicamente quero manter minha configuração para todos os softwares, exceto para coisas voláteis e alguns softwares que não me interessam. Quando você mais tarde mescla, migra ou compara sistemas, poder diferenciar tudo é bastante útil. Você pode configurar seus novos sistemas muito mais rápido do que se você tivesse apenas .bashrc e alguns outros dotfiles armazenados. Dessa forma, você manterá a configuração que você poderia definir através da GUI, e não saberá quais os dotfiles armazenam as configurações. (Se acontecer de você ter cometido arquivos voláteis, você ainda pode dizer ao git para assumir-inalterado)
5. executar etckeeper init -d /home/username
6. executar git commit -d /home/username
7. configure os aliases no seu shell para tornar a linha de comando mais agradável, como homekeeper checkout

A razão para usar o etckeeper é que ele armazenará metadados como permissões para seus arquivos (bastante importantes para certas coisas como chaves ssh). Agora você deve ter um gancho de pré-consolidação que salvará os metadados automaticamente. Não tenho tanta certeza sobre o pós-pagamento. Provavelmente você deveria usar etckeeper checkout xxx -d /home/user , vou examinar isso um pouco mais e elaborar essa resposta.

    

Answer 7

Meu maior problema com o uso do Git no diretório inicial é que o Git não armazena atributos de arquivos, como permissões de arquivo e registros de data e hora. Para mim, é importante saber quando determinados arquivos foram criados, o que pode ou não ser o caso para você. Além disso, perder permissões para arquivos e diretórios como .ssh é problemático. Eu entendo que você planeja manter .ssh fora do Git, mas haverá outros lugares onde as permissões podem ser importantes (como backups de sites descompactados).

    

Answer 8

Uma solução baseada em git é especialmente útil se você precisar implantar seus arquivos em máquinas diferentes e, mais ainda, se tiver partes comuns a todas as máquinas e peças específicas de algumas máquinas. Você pode fazer vários repositórios e usar uma ferramenta como multigit ou vcsh para cloná-los no mesmo diretório (seu diretório home neste caso).