Dicas para colocar ~ sob controle de origem

Question

Eu quero colocar meu diretório home (~) sob o controle de origem (git, neste caso), como eu tenho muitos arquivos de configuração (.gitconfig, .gitignore, .emacs, etc) lá eu gostaria de levar através de máquinas, e tê-las no Git seria bom para recuperá-las.

Minha máquina principal é o meu MacBook e a maneira que o OS X é configurado, há muitas pastas que eu quero ignorar (Documents, Downloads, .ssh). Também existem pastas que já estão usando o Git (.emacs.d).

Meu pensamento era apenas adicionar todos esses diretórios ao meu arquivo .gitignore, mas isso parece cansativo e poderia levar a algumas conseqüências imprevistas. Meu próximo pensamento foi periodicamente copiar os arquivos que eu quero armazenar em alguma pasta em casa, então confirmar essa pasta. O problema com isso será que eu tenho que lembrar de movê-los antes de cometer.

Existe uma maneira limpa de fazer isso?

    

Answer 1

Eu tenho $HOME sob git. A primeira linha do meu arquivo .gitignore é

/*

O resto são padrões para não ignorar usando o modificador ! . Esta primeira linha significa que o padrão é ignorar todos os arquivos no meu diretório pessoal. Esses arquivos que eu quero para o controle de versão vão para .gitignore assim:

!/.gitignore
!/.profile
[...]

Um padrão mais complicado que eu tenho é:

!/.ssh
/.ssh/*
!/.ssh/config

Ou seja, eu quero apenas a versão .ssh/config - não quero que minhas chaves e outros arquivos em .ssh entrem no git. O acima é como eu consegui isso.

Editar: Adicionadas barras ao início de todos os caminhos. Isso faz com que os padrões de ignorar correspondam do topo do repositório ($ HOME) em vez de em qualquer lugar. Por exemplo, se !lib/ fosse um padrão (não ignore tudo no diretório lib) e você incluísse um arquivo .gitignore , anteriormente, o padrão ( !.gitignore ) estaria correspondendo a isso. Com a barra inicial ( !/.gitignore ), ele corresponderá apenas a .gitignore no meu diretório inicial e não em nenhum subdiretório.

Eu não vi um caso em que isso faz uma diferença prática com minha lista de ignorados, mas parece-me ser tecnicamente mais preciso.

    

Answer 2

O que eu faço (com os mesmos objetivos) é colocar meus arquivos de configuração em um subdiretório ~/lib e ter links simbólicos no meu diretório pessoal, por exemplo, .emacs -> lib/emacs/dot.emacs . Eu só mantenho arquivos de configuração que escrevi explicitamente sob controle de versão; Meu diretório home contém plenos arquivos de pontos criados automaticamente que não estão sob controle de versão. Portanto ~/lib está sob controle de versão e meu diretório pessoal não é.

Eu tenho um script que cria os links simbólicos dos arquivos em ~/lib . Quando eu crio uma conta em uma nova máquina, eu a preencho marcando ~/lib e executando esse script.

Minha experiência é com o CVS, não git, por isso não é 100% transferível. Uma das razões pelas quais não coloquei meu diretório pessoal diretamente sob o CVS é que ~/.cvsignore se aplicaria a todos os check-outs do meu CVS e não apenas ao meu diretório pessoal; git não tem esse problema. A desvantagem dessa abordagem em comparação com ter o diretório home sob controle de versão é que você não pode usar git status para distinguir entre um arquivo que você decidiu ignorar explicitamente (que seria listado no arquivo de ignorar, portanto, não exibido ) e um arquivo sobre o qual você não tem opinião (que seria exibido com um ? ).

Alguns arquivos precisam ser diferentes em máquinas diferentes. Eu os coloco em um diretório chamado ~/Local/SITENAME/lib e também crio links simbólicos para eles ou (para formatos de arquivo que o suportam) tenho uma diretiva include no arquivo em ~/lib . Eu também tenho um link simbólico ~/Here -> ~/Local/SITENAME . Como o git, ao contrário do CVS, é projetado para suportar repositórios na maioria das vezes semelhantes, mas não idênticos, pode haver uma maneira melhor de gerenciar arquivos específicos da máquina. Alguns dos meus arquivos de ponto não são links simbólicos, mas são gerados automaticamente a partir do conteúdo em ~/lib e ~/Here .

    

Answer 3

Podemos usar a capacidade do Git para continuar rastreando arquivos, mesmo que eles estejam listados em .gitignore . Então, isso é suficiente para .gitignore :

$ cat .gitignore
/*

Para cada arquivo que você deseja acompanhar, execute add -f (o parâmetro -f substitui os dois em .gitignore e .git/info/exclude ):

git add -f .gitignore
git add -f .profile
git add -f .zshrc
git add -f .ssh/config

Após indexar um arquivo, o Git rastreará todas as alterações, apesar do fato de o arquivo ser ignorado. O mesmo funciona para um diretório, mas apenas para os arquivos que estão realmente presentes:

git add -f somedirname

Se você deseja rastrear um diretório inteiro com todos os novos arquivos que aparecem nele, ele pode ser excluído de .gitignore de uma maneira, descrito no answer by camh :

!/somedirname

Se você quiser parar de rastrear um arquivo, esse comando remove um arquivo do índice do Git, mas não o mantém no disco rígido:

git rm --cached .ssh/config

    

Answer 4

Eu uso o antigo rcs para isso.

Dê uma olhada nas páginas de manual para ci , co e rcs . Esses sites também devem ser úteis:

• link
• link
• link

Eu uso isso para a versão que controla meus dotfiles, por exemplo:

ci -u .*vimrc

E se eu quiser editá-los:

co -l .*vimrc

Eu recomendo criar um diretório chamado RCS no seu ~ , então você pode facilmente fazer o backup desse diretório em algum lugar.

    

Answer 5

Eu verifico meus arquivos de configuração para $HOME/.conf/ de um repositório do BitBucket Mercurial. Um repositório do GitHub funcionaria também.

A saída ~/.conf contém arquivos de configuração e um script de shell para preencher links simbólicos em $HOME para cada arquivo em ~/.conf . Para formatos de configuração que suportam inclusão ( .bashrc , .inputrc , .vimrc , etc.) incluo o arquivo ~/.conf em vez de linkar para ele, para que eu possa fazer substituições locais.

Para alguns arquivos de configuração eu faço links simbólicos para um arquivo na minha pasta do Dropbox e compartilho via dropbox.

Por alguns meses eu tentei manter o $HOME em controle de versão, mas eu cansei de gerenciar as enormes listas de ignorados, cansei de checar as mudanças de configuração feitas pelos aplicativos em execução, e o resultado nem era algo que eu gostaria confira em outro computador. Você pode imaginar a correção de conflitos em relação a ~/.gconf ou ~/.config/monitors.xml ou a restauração de versões diferentes de aplicativos de área de trabalho?

Acho mais fácil vincular ou incluir uma lista limitada de arquivos de configuração que eu pessoalmente personalizei e quero compartilhar em máquinas como padrões globais.

    

Answer 6

Acabei de começar a usar o seguinte script Dotfiles do Python, que é uma ferramenta útil que vincula automaticamente os arquivos para você: link

    

Answer 7

Acho que seu segundo palpite de ter uma pasta não relacionada no controle de origem é bom.

Apenas adicione 2 scripts de shell lá. Um para copiar arquivos sob seu controle para ~ e o outro para coletar arquivos de ~ e copiá-lo de volta para a pasta controlada por fonte e confirmar.

    

Answer 8

Aqui está um pequeno script ruby que eu uso para configurar uma nova máquina

#!/usr/bin/env ruby
# setup.rb

#list of dirs which you don't want to symlink
ignored = %w(.gitignore .gitmodules misc setup.rb readme)

current_dir = File.expand_path(Dir.pwd)
home_dir = File.expand_path("~")

links = 'git ls-tree --name-only HEAD'.lines.map(&:strip).select {|x| !ignored.include?(x)  }

links.each do |link|
  link = File.join(current_dir, link)
  symlink = File.join(home_dir, File.basename(link))
  'ln -ns #{link} #{symlink}'
end