概述+问题

我想要类似etckeeper的文件系统元数据控制非git控制的目录。主目录和Web应用程序目录等通常对元数据（文件所有权，ACL，权限）敏感。这对于将git用于自动化服务器部署（以及诸如Fabric之类的工具）非常有用/重要。我想在etcdir上重新使用类似etckeeper的功能，或者与etckeeper本身或其他一起使用。

任何人都可以提出任何提示/技巧/可行的解决方案来提供以下一项或两项建议：

1. 将etckeeper引擎（仅关心etckeeper的git特定功能）应用于非/ etc，git控制的目录。（至少可以假设使用Debian / Ubuntu Linux；如果可能，希望MacOSX / 自制软件支持。）
2. 用元数据支持扩展git（除了像git-cache-meta这样过分简化的东西之外）以支持类似etckeeper的功能或更好？

更多细节，背景

使用文件系统元数据控制功能扩展git的兴趣日益浓厚。根据我的经验，etckeeper的元数据“引擎”似乎功能强大且可靠，而etckeeper似乎也很受其他人欢迎。 metastore没有那么至少部分归因于metastore的非基于文本/合并不友好的挑战。此外，etckeeper似乎从基于Metastore的核心开始，但随后切换到了自己的（推测性的）。

显然，这具有特定于OS /文件系统的依赖性。（例如，不尝试在Windows上自动部署。）建议使用可选git的扩展（如果是“本机扩展”），由用户按需启用，并具有跨平台破坏的后果，从而使本机行为不会破坏git的“默认情况下”跨平台友好性。此外，不需要保存奢侈的unix / darwin / etc元数据（例如ACL）；基本用户/组/其他权限和用户/组所有权。（这些是目前破坏我的“安全性/漏洞控制/策略”的唯一事物。）我预先针对特定的操作系统：Debian，Ubuntu，MacOS 10.6+。后来：Redhat（CentOS，Fedora，RHEL），SUSE（可能还有其他Linux）和* BSD（FreeBSD，NetBSD，OpenBSD）。在任何可预见的地方，都看不到Windows / VMS（即使VMS可以对posix友好）或其他非类Unix操作系统的需求/应用程序。

另请参阅：有关我发布的这个stackoverflow问题的 git，文件元数据/文件类型跟踪功能的背景知识。

制定新项目的要求？

另外：如果有人在乎对此功能的要求，我相信这可能会有用，特别是对于上面要解决的新项目/未完成项目。

根据此serverfault答案，您只需执行以下操作：

在手册页中。

• 建立目录 /foo
• 用etckeeper初始化： etckeeper -d /foo init
• 提交将提交提交到目录： etckeeper -d /foo commit 'message'

我研究了这个问题，并决定为此创建一个项目git-store-meta。

git-store-meta是一个perl脚本，它集成了git-cache-meta，metastore，setgitperms和mtimestore的漂亮功能。它应该在灵活性，功能性，性能以及跨平台可移植性和一致性方面取得很好的折衷。