Update: 2020-09-22
==================

After having used it a while (years?), [etckeeper](https://etckeeper.branchable.com)+git does not meet the requirements I seek.

Overview + question
===================

I want [etckeeper](https://joeyh.name/code/etckeeper/)-like filesystem metadata control for non-/etc, git-controlled directories. Home and web-app directories, among others, are classically sensitive to metadata (file ownership, ACL, permissions). This can be extremely useful/important to employ git for [automated server deployment](https://web.archive.org/web/20121108151859/http://mig5.net/node/342) (along with tools like [Fabric](https://www.fabfile.org/)), among other things. I would like to re-use etckeeper-like capability on said dirs, either with etckeeper itself or something else.

Can anyone suggest any tips/tricks/working solutions to provide either or both of the following:

1. apply the etckeeper engine (only care about the git-specific capability of etckeeper) to non-/etc, git-controlled directories. (Can assume at least Debian/Ubuntu Linux; would like MacOSX/[homebrew](https://brew.sh/) support if possible.)
2. extend git with metadata support (beyond over-simplified things like [git-cache-meta](http://www.kerneltrap.org/mailarchive/git/2009/1/9/4654694)) to support an etckeeper-like capability or better?

More details, background
========================

There's a growing interest in [extending git with filesystem-metadata-control capabilities](http://git.661346.n2.nabble.com/Tracking-file-metadata-in-git-fix-metastore-or-enhance-git-td6251248.html). [etckeeper's](https://joeyh.name/code/etckeeper/) metadata "engine" seems quite powerful and reliable in my experience, and [etckeeper seems popular with others](http://git.661346.n2.nabble.com/Tracking-file-metadata-in-git-fix-metastore-or-enhance-git-td6251248.html#a6282162) as well. [metastore less so](http://git.661346.n2.nabble.com/Tracking-file-metadata-in-git-fix-metastore-or-enhance-git-td6251248.html#a6282162) at least in part due to [metastore's non-text-based/merge-unfriendly challenges](http://git.661346.n2.nabble.com/Tracking-file-metadata-in-git-fix-metastore-or-enhance-git-td6251248.html). Further, etckeeper appears to have started with a metastore-based core, but then switched to its own (speculative?).

Obviously, this has OS/filesystem-specific dependencies. (eg, not trying to auto-deploy on Windows.) Suggest an **optional** extension (if it's a "native extension") of git, enabled on-demand by the user with understood consequences of cross-platform breakage, such that native behavior doesn't break git's "by default" cross-platform friendliness. Further, don't need to save extravagant unix/darwin/etc metadata (like ACLs); basic user/group/other perms and user/group ownership would be fine. (These are the only things that are currently breaking things in my "security/vulnerability control/policies.") Specific OSes I'm targeting up front: Debian, Ubuntu, MacOS 10.6+. Later: Redhat's (CentOS, Fedora, RHEL), SUSE, maybe other Linuxes, and \*BSD (FreeBSD, NetBSD, OpenBSD). Don't see a need/application for Windows/VMS (even though VMS can be posix-friendly) or other non-unix-like OSes at any foreseeable point.

See also: background on pre-existing git, file-metadata/file-type tracking capabilities at [this stackoverflow question I posted](https://stackoverflow.com/questions/8521938/what-does-git-commit-mean-when-it-says-create-mode-on-stdout).

Develop requirements for a new project?
=======================================

Additionally: if anyone cares to develop requirements for such capability, I am sure that could prove useful, particularly for a new/uncompleted project to address above.