更新日期：2020-09-22
使用了一段时间（几年？）后，etckeeper+git 不能满足我的要求。
概述 + 问题
我想etckeeper类似于文件系统元数据控制，用于非 /etc、git 控制的目录。主目录和 web-app 目录等通常对元数据（文件所有权、ACL、权限）敏感。这对于使用 git 进行以下操作非常有用/重要自动化服务器部署（以及类似织物)，等等。我想在上述目录上重新使用类似 etckeeper 的功能，无论是使用 etckeeper 本身还是其他东西。
有人可以建议任何技巧/窍门/可行的解决方案来提供以下一项或两项：
- 将 etckeeper 引擎（仅关心 etckeeper 特定于 git 的功能）应用于非 /etc、git 控制的目录。（至少可以假设 Debian/Ubuntu Linux；希望是 MacOSX/自制尽可能提供支持。
- 扩展 git 的元数据支持（超越过于简单的事情，如git 缓存元) 来支持类似 etckeeper 的功能或者更好的功能？
更多细节、背景
人们越来越感兴趣使用文件系统元数据控制功能扩展 git。etckeeper的根据我的经验，元数据“引擎”似乎非常强大和可靠，并且etckeeper 似乎很受其他人欢迎也一样。 元存储则不然至少部分原因是Metastore 的非基于文本/不利于合并的挑战。此外，etckeeper 似乎是从基于 metastore 的核心开始的，但后来切换到了自己的核心（推测？）。
显然，这具有特定于操作系统/文件系统的依赖关系。（例如，不尝试在 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 操作系统的需求/应用程序。
另请参阅：现有 git 的背景、文件元数据/文件类型跟踪功能我发布的这个 stackoverflow 问题。
为新项目制定需求？
此外：如果有人愿意开发这种能力的要求，我相信这将是有用的，特别是对于上述新的/未完成的项目。
答案1
根据这个 serverfault 答案，你只需这样做：
它就在手册页。
- 创建目录
/foo- 使用 etckeeper 进行初始化：
etckeeper -d /foo init- 提交将提交应用于目录：
etckeeper -d /foo commit 'message'
答案2
我深入研究了这个问题，并决定创建一个项目git-store-meta为了它。
git-store-meta 是一个 perl 脚本，它集成了 git-cache-meta、metastore、setgitperms 和 mtimestore 的优秀功能。它在灵活性、功能性、性能以及跨平台可移植性和一致性之间取得了良好的平衡。