Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Overview + question

I want 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 (along with tools like Fabric), 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 support if possible.)
  2. extend git with metadata support (beyond over-simplified things like git-cache-meta) to support an etckeeper-like capability or better?

More details, background

There's a growing interest in extending git with filesystem-metadata-control capabilities. etckeeper's metadata "engine" seems quite powerful and reliable in my experience, and etckeeper seems popular with others as well. metastore less so at least in part due to metastore's non-text-based/merge-unfriendly challenges. 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.

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.

share|improve this question
fyi. Found this Q&A on ServerFault: Can etckeeper be used to track config files outside of /etc?. – Johnny Utahh Dec 14 '11 at 21:50
You could probably accomplish this using some (potentially sophisticated) git hooks. – Justin ᚅᚔᚈᚄᚒᚔ Dec 15 '11 at 16:31
Custom hooks: right, like with git-cache-meta as mentioned above; useful, but an oversimplified solution. Alas, looking to "push" this functionality beyond user-custom hooks into something "community owned" for better functionality/reliability/features/codereview/etc. Further, don't want to write it from scratch, at least not by myself. – Johnny Utahh Dec 15 '11 at 16:41
fyi. My question from stackoverflow: What does 'git commit' mean when it says 'create mode …' on stdout? – Johnny Utahh Dec 15 '11 at 16:46
Any updates here? – cregox Jul 19 '13 at 16:30

According to this serverfault answer, you just do this:

It is right there in the man page.

  • Create a directory /foo
  • Initialize with etckeeper: etckeeper -d /foo init
  • Commit apply commits to the directory: etckeeper -d /foo commit 'message'
share|improve this answer
Quite interesting. I can't find any etckeeper ports/tests running on Mac OS X. Nothing in homebrew nor anywhere else substantial. Anybody know of anything? – Johnny Utahh Jan 21 '14 at 3:19
I'm asking etckeeper's suggestions for Mac OS X porting here: – Johnny Utahh Feb 7 '14 at 20:37
@JohnnyUtahh: doesn't seem to have been any response from Joey or anyone else... have you made any progress on an OS X port? – iconoclast Nov 23 '15 at 3:27
@JohnnyUtahh: by the way, I found this: – iconoclast Nov 23 '15 at 3:56
@iconoclast I've done no work towards an OS X port, or any work on this project, for that matter. looks useful - thanks! – Johnny Utahh Nov 23 '15 at 4:32

I digged in this problem and I decided to create a project git-store-meta for it.

git-store-meta is a perl script which integrates the nice features of git-cache-meta, metastore, setgitperms, and mtimestore. It should serve a good compromise of the flexibility, functionality, performance, and cross-platform portability and consistency.

share|improve this answer
I haven't yet found time to test and review git-store-meta, but at first glance it looks thorough, and quite promising. Quite appreciated. I very much look forward to testing this. Thanks again, @Danny Lin. – Johnny Utahh May 4 '15 at 4:55
@'Danny Lin', I've referenced git-store-meta at my related, stackoverflow question. – Johnny Utahh May 13 '15 at 17:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .