Resumen + pregunta

Quiero un control de metadatos del sistema de archivos similar a etckeeper para directorios no controlados por git, etc. Los directorios de inicio y de aplicaciones web, entre otros, son clásicamente sensibles a los metadatos (propiedad de archivos, ACL, permisos). Esto puede ser extremadamente útil / importante para emplear git para la implementación automatizada de servidores (junto con herramientas como Fabric ), entre otras cosas. Me gustaría reutilizar la capacidad de etckeeper en dichos directorios, ya sea con etckeeper o con otra cosa.

¿Alguien puede sugerir algún consejo / truco / solución de trabajo para proporcionar uno o ambos de los siguientes:

1. aplique el motor etckeeper (solo se preocupan por la capacidad específica de git de etckeeper) a directorios no controlados por git, etc. (Puede suponer al menos Debian / Ubuntu Linux; quisiera MacOSX / homebrew si es posible).
2. ¿Extiende git con soporte de metadatos (más allá de cosas demasiado simplificadas como git-cache-meta ) para soportar una capacidad similar a etckeeper o mejor?

Más detalles, antecedentes

Hay un creciente interés en extender git con capacidades de control de metadatos del sistema de archivos . El "motor" de metadatos de etckeeper parece bastante potente y confiable en mi experiencia, y etckeeper también parece popular entre los demás . metastore no tanto, al menos en parte debido a los desafíos no metas / merge-amigable de metastore . Además, etckeeper parece haber comenzado con un núcleo basado en metastore, pero luego cambió a su propio (¿especulativo?).

Obviamente, esto tiene dependencias específicas del sistema operativo / sistema de archivos. (p. ej., no intentar la implementación automática en Windows). Sugerir una opciónextensión (si es una "extensión nativa") de git, habilitada bajo demanda por el usuario con las consecuencias entendidas de la ruptura multiplataforma, de modo que el comportamiento nativo no rompa la amistad multiplataforma "por defecto" de git. Además, no es necesario guardar metadatos extravagantes de unix / darwin / etc (como ACL); usuario básico / grupo / otros permisos y propiedad de usuario / grupo estaría bien. (Estas son las únicas cosas que actualmente están rompiendo cosas en mis "políticas / control de seguridad / vulnerabilidad".) Sistemas operativos específicos a los que me dirijo desde el principio: Debian, Ubuntu, MacOS 10.6+. Más tarde: Redhat's (CentOS, Fedora, RHEL), SUSE, tal vez otros Linux y * BSD (FreeBSD, NetBSD, OpenBSD). No veo una necesidad / aplicación para Windows / VMS (aunque VMS puede ser compatible con posix) u otros sistemas operativos no similares a Unix en cualquier momento previsible.

Ver también: antecedentes sobre git preexistente, capacidades de seguimiento de metadatos de archivo / tipo de archivo en esta pregunta de stackoverflow que publiqué .

¿Desarrollar requisitos para un nuevo proyecto?

Además: si a alguien le interesa desarrollar requisitos para dicha capacidad, estoy seguro de que podría resultar útil, particularmente para un proyecto nuevo / incompleto que se abordará anteriormente.

De acuerdo con esta respuesta predeterminada del servidor , simplemente haga esto:

Está justo allí en la página del manual .

• Crea un directorio /foo
• Inicializar con etckeeper: etckeeper -d /foo init
• Confirmar aplicar confirma al directorio: etckeeper -d /foo commit 'message'

Investigué este problema y decidí crear un proyecto git-store-meta para él.

git-store-meta es un script perl que integra las características agradables de git-cache-meta, metastore, setgitperms y mtimestore. Debe servir un buen compromiso de flexibilidad, funcionalidad, rendimiento y portabilidad y consistencia multiplataforma.