Visão geral + pergunta

Eu quero o controle de metadados do sistema de arquivos do tipo etckeeper para diretórios não controlados por / etc, 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 automatizada de servidores (junto com ferramentas como o Fabric ), entre outras coisas. Eu gostaria de reutilizar o recurso do tipo etckeeper nos diretórios, seja com o próprio etckeeper ou qualquer outra coisa.

Alguém pode sugerir quaisquer dicas / truques / soluções de trabalho para fornecer um ou ambos dos seguintes:

1. aplicar o mecanismo do etckeeper (apenas se preocupe com a capacidade específica do git do etckeeper) para diretórios não-controlados por / git. (Pode assumir pelo menos Debian / Ubuntu Linux; gostaria de suporte a MacOSX / homebrew, se possível.)
2. estender git com suporte a metadados (além de coisas simplificadas como git-cache-meta ) para suportar uma capacidade do tipo etckeeper ou melhor?

Mais detalhes, fundo

Há um interesse crescente em estender 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 o etckeeper parece popular com os outros também. metastore menos, pelo menos em parte devido aos desafios não baseados em texto / hostil de mesclagem do metastore . Além disso, o etckeeper parece ter começado com um núcleo baseado em 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.) Sugira um opcionalextensão (se for uma "extensão nativa") do git, habilitado sob demanda pelo usuário com conseqüências conhecidas de quebra de plataforma cruzada, de tal forma que o comportamento nativo não quebra a facilidade de compatibilidade entre plataformas do Git "por padrão". Além disso, não é necessário salvar metadados unix / darwin / etc extravagantes (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 eu 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: background em recursos de git preexistentes, metadados de arquivos / rastreamento de tipo de arquivo nesta pergunta de stackoverflow que eu publiquei .

Desenvolver requisitos para um novo projeto?

Além disso: se alguém quiser desenvolver requisitos para essa capacidade, tenho certeza de que isso poderia ser útil, particularmente para um projeto novo / incompleto para abordar acima.

De acordo com esta resposta de falha de servidor , você apenas faz isto:

Está bem ali na man page .

• Crie um diretório /foo
• Inicialize com o etckeeper: etckeeper -d /foo init
• Commit aplicar commits no diretório: etckeeper -d /foo commit 'message'

Eu investiguei esse problema e decidi criar um projeto git-store-meta para ele.

O git-store-meta é um script perl que integra os recursos interessantes do git-cache-meta, metastore, setgitperms e mtimestore. Deve servir para um bom compromisso da flexibilidade, funcionalidade, desempenho e portabilidade e consistência entre plataformas.