如何重用/扩展 etckeeper 的元数据引擎来控制非 /etc 文件系统，或使用上述功能在本地扩展 git？

Question

更新：2020-09-22

使用一段时间后（几年？），etckeeper +git 不符合我寻求的要求。

概述 + 问题

我想要类似 etckeeper的文件系统元数据控制，用于非/etc、git 控制的目录。Home 和 web-app 目录等通常对元数据（文件所有权、ACL、权限）敏感。这对于使用 git 进行自动化服务器部署（以及诸如Fabric 之类的工具）非常有用/重要。我想在上述目录上重新使用类似 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 的核心开始的，但后来转向了自己的（推测性的？）。

显然，这具有特定于操作系统/文件系统的依赖性。（例如，不要尝试在 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、文件元数据/文件类型跟踪功能的背景。

开发新项目的需求？

另外：如果有人关心开发此类功能的需求，我相信这可能会很有用，特别是对于要解决上述问题的新/未完成项目。

Answer 1

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

它就在手册页中。

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