ti-enxame.com

Dicas para colocar ~ sob controle de origem

Quero colocar meu diretório pessoal (~) sob controle de origem (git, neste caso), pois tenho muitos arquivos de configuração (.gitconfig, .gitignore, .emacs, etc.) por lá, gostaria de transportar máquinas, tê-los no Git seria bom recuperá-los.

Minha máquina principal é o meu MacBook e, da maneira como o OS X está configurado, há muitas pastas que quero ignorar (Documentos, 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 meio cansativo e pode levar a consequências imprevisíveis. Meu próximo pensamento era copiar periodicamente os arquivos que eu quero armazenar em alguma pasta em casa e 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?

78
Dan McClain

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

/*

O restante são padrões para não ignorar usando o ! modificador. Essa primeira linha significa que o padrão é ignorar todos os arquivos no meu diretório pessoal. Os arquivos que eu quero controlar a versão entram em .gitignore como isso:

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

Um padrão mais complicado que tenho é:

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

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

Editar: barras adicionadas ao início de todos os caminhos. Isso faz com que os padrões de ignorar correspondam na parte superior do repositório ($ HOME) em vez de em qualquer lugar. Por exemplo, se !lib/ era um padrão (não ignore tudo no diretório lib) e você adiciona um arquivo .gitignore, anteriormente o padrão (!.gitignore) estava combinando isso. Com a barra principal (!/.gitignore), ele corresponderá apenas a .gitignore no meu diretório pessoal e não em nenhum subdiretório.

Não vi um caso em que isso faça uma diferença prática na minha lista de ignorados, mas parece-me mais tecnicamente preciso.

60
camh

O que faço (com os mesmos objetivos) é colocar meus arquivos de configuração em um subdiretório ~/lib e possui links simbólicos no meu diretório pessoal, por exemplo, .emacs -> lib/emacs/dot.emacs. Eu apenas mantenho os arquivos de configuração que escrevi explicitamente sob controle de versão; meu diretório pessoal contém muitos 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 inicial não.

Eu tenho um script que cria os links simbólicos dos arquivos em ~/lib. Quando crio uma conta em uma nova máquina, preencha-a fazendo check-out ~/lib e executando esse script.

Minha experiência é com CVS, não com git, portanto não é 100% transferível. Uma das razões pelas quais eu não coloquei meu diretório inicial diretamente no CVS é ​​que ~/.cvsignore se aplicaria a todos os meus checkout do CVS e não apenas ao meu diretório pessoal; O git não tem esse problema. A desvantagem dessa abordagem em comparação com o diretório inicial sob controle de versão é que você não pode usar git status para distinguir entre um arquivo que você decidiu explicitamente ignorar (que seria listado no arquivo 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 coloquei em um diretório chamado ~/Local/SITENAME/lib e crie links simbólicos para eles também ou (para os formatos de arquivo que o suportam) possuem uma diretiva de inclusão no arquivo em ~/lib. Eu também tenho um link simbólico ~/Here -> ~/Local/SITENAME. Como o git, diferentemente do CVS, foi projetado para suportar repositórios quase similares, mas não idênticos, pode haver uma maneira melhor de gerenciar arquivos específicos da máquina. Na verdade, 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.

24

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

$ cat .gitignore
/*

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

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

Depois de 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 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 certa forma, descrito em resposta por camh :

!/somedirname

Se você quiser parar de rastrear um arquivo, esse comando remove um arquivo do índice do Git, mas o deixa intocado no disco rígido:

git rm --cached .ssh/config
11
Nick Volynkin

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

O ~/.conf checkout contém arquivos de configuração e um script do Shell para preencher links simbólicos em $HOME para cada arquivo em ~/.conf. Para formatos de configuração compatíveis com inclusão (.bashrc, .inputrc, .vimrc, etc.) eu incluo o ~/.conf em vez de vincular a ele, para que eu possa fazer substituições locais.

Para alguns arquivos de configuração, eu ligo para um arquivo na minha pasta Dropbox e os compartilho via dropbox.

Por alguns meses eu tentei manter $HOME em controle de versão, mas eu cansei de gerenciar as enormes listas de ignorados, cansei de verificar as alterações de configuração feitas pelos aplicativos em execução, e o resultado não era algo que eu gostaria de verificar em outro computador. Você pode imaginar consertando conflitos por ~/.gconf ou ~/.config/monitors.xml, ou atendendo a diferentes versões de aplicativos de desktop?

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

5
Graham

Eu uso o antigo rcs para isso.

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

Eu uso isso para controlar a versão dos 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 ~, você pode facilmente fazer backup desse diretório em algum lugar.

5
polemon

Acabei de começar a usar o seguinte script Python Dotfiles, que é uma ferramenta útil que vincula automaticamente os arquivos para você: https://pypi.python.org/pypi/dotfiles

3
trojjer

Eu acho que o seu segundo palpite de ter pasta não relacionada sob controle de origem é bom.

Basta adicionar 2 scripts de shell lá. Um para copiar arquivos sob seu controle para ~ e o outro para coletar arquivos de ~ e copie-o novamente para a pasta controlada pela fonte e confirme.

1
Alexander Pogrebnyak

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
0
Khaja Minhajuddin