De acordo com esta resposta do servidor , basta fazer isso:
It is right there in the man page.
- Create a directory
/foo- Initialize with etckeeper:
etckeeper -d /foo init- Commit apply commits to the directory:
etckeeper -d /foo commit 'message'
Eu quero o etckeeper - como o controle de metadados do sistema de arquivos para diretórios não / etc, controlados por git. Diretórios domésticos e de aplicativos da web, entre outros, são classicamente sensíveis aos metadados (propriedade de arquivo, ACL, permissões). Isso pode ser extremamente útil / importante para empregar o git para implantação automática de servidores (junto com ferramentas como Fabric , entre outras coisas. Eu gostaria de reutilizar o recurso do etckeeper em dirs, seja com o próprio etckeeper ou qualquer outra coisa.
Alguém pode sugerir dicas / truques / soluções de trabalho para fornecer um ou ambos dos seguintes itens:
Há um interesse crescente em estendendo o git com recursos de controle de metadados do sistema de arquivos . O "mecanismo" de metadados do etckeeper parece bastante poderoso e confiável na minha experiência, e etckeeper parece popular com os outros também. metastore less so pelo menos em parte devido a desafios metastore não baseados em texto / unge-hostil . Além disso, o etckeeper parece ter começado com um núcleo baseado no metastore, mas depois mudou para o seu próprio (especulativo?).
Obviamente, isso tem dependências específicas do SO / sistema de arquivos. (por exemplo, não tentar implantar automaticamente no Windows.) Sugerir uma extensão opcional (se for uma "extensão nativa") do git, ativada sob demanda pelo usuário com consequências conhecidas de plataforma cruzada quebra, tal que o comportamento nativo não quebra a facilidade de compatibilidade entre plataformas do "por padrão" do git. Além disso, não é necessário salvar metadados extravagantes de unix / darwin / etc (como ACLs); usuário básico / grupo / outros perms e propriedade de usuário / grupo ficariam bem. (Essas são as únicas coisas que atualmente estão quebrando as coisas em meu "controle / políticas de segurança / vulnerabilidade".) SOs específicos que estou mirando na frente: Debian, Ubuntu, MacOS 10.6+. Mais tarde: Redhat (CentOS, Fedora, RHEL), SUSE, talvez outros Linuxes, e * BSD (FreeBSD, NetBSD, OpenBSD). Não vejo necessidade / aplicação para Windows / VMS (mesmo que o VMS possa ser posix-friendly) ou outros sistemas operacionais não-unix-like em qualquer ponto previsível.
Veja também: experiência em recursos de rastreamento de metadados de arquivos, metadados de arquivos / tipos de arquivos preexistentes em esta pergunta stackoverflow eu postei .
Além disso: se alguém quiser desenvolver requisitos para essa capacidade, tenho certeza de que isso pode ser útil, especialmente para um projeto novo / incompleto a ser abordado acima.
De acordo com esta resposta do servidor , basta fazer isso:
It is right there in the man page.
- Create a directory
/foo- Initialize with etckeeper:
etckeeper -d /foo init- Commit apply commits to the directory:
etckeeper -d /foo commit 'message'
Eu investiguei esse problema e decidi criar um git-store-meta para ele.
git-store-meta é um script perl que integra os recursos interessantes do git-cache-meta, metastore, setgitperms e mtimestore. Ele deve ter um bom compromisso com a flexibilidade, funcionalidade, desempenho e portabilidade e consistência entre plataformas.
Tags git metadata linux filesystems