I want to track changes in a directory tree with git.

Needed features:

  • track permissions (chmod, chown). ACLs not needed
  • track mtime
  • automatically add new files
  • automatically delete files
  • command line. GUI not needed
  • open source

I could solve this with shell scripting, but I don't want to reinvent the wheel. And I guess there are some corner cases which I are not on my mind today, but which are already solved.

Timing is not important. One commit per day is enough.

I looked at etckeeper. But it seems to focused on managing /etc. I would like to have a general purpose tool which can track any directory.

I am not looking for inotify (event handling if file was changed) or something like this.

  • So you want to automate tracking changes happening, and commit a snapshop once per day atleast? facebook.github.io/watchman and a cron job is kind of what you're looking for?
    – Jahhein
    Apr 30, 2018 at 9:34
  • @Jahhein I want to track changes in git. I looked at Watchman. This is a great tool. But I think it solves a different use case. I don't want to do anything if the file changes. I just want a daily commit.
    – guettli
    Apr 30, 2018 at 9:42
  • Okay, I think you need to actually read the git documentation. Git, simply put, adds a file at state (1), checks it shasum (checksum) and when you check for changes, it recomputes the checksums to see if they are different to determine changes made to files. It is not automatic, you must run the commands yourself. To learn how to use it, see git-scm.com/doc and the manual pages.
    – Jahhein
    Apr 30, 2018 at 9:44
  • @Jahhein are you sure git would catch permission changes (chmod/chown)? Because that's one thing etckeeper documentation says it does not (and thus etckeeper takes care for itself).
    – Izzy
    Apr 30, 2018 at 9:47
  • @Izzy yes, git catches access permissions but not group changes.
    – Jahhein
    Apr 30, 2018 at 9:48

3 Answers 3


User Izzy pointed me to a different question, where I found this:


git-store-meta is a light-weight tool for file metadata storing and applying for Git.


Light dependency, cross-platform consistent behavior, desirable performance.

Data files are in plain text format and can be easily revisioned, diffed, or manually modified as needed.

Supported metadata: mtime, atime, mode, user, uid, group, gid, acl.

Can store the metadata of git-revisioned files into a data file.

Can apply the metadata stored in the data file to the working copy.

Can update the metadata for changed files quickly.

Can easily pick which metadata fields to store, update, or apply.

Can determine whether to store, update, or apply directory metadata.

AFAIK it does not solve these required features:

  • automatically add new files
  • automatically delete files

Though you've already looked at it and discarded it, etckeeper would match your needs. Yes, it focuses on /etc – but with its command-line parameter -d it can be used for other locations as well. Also see its man page:

etckeeper command [-d directory]

I've not tried that myself, but found it mentioned this way in multiple posts at e.g. SU/SF.

Let's see how it meets your requirements:

  • track permissions (chmod, chown): it does track those in its own files
  • track mtime: not sure about that, as I haven't (yet) used and verified it
  • automatically add new files: partially (it does so in /etc whenever a package update/install was taking place) – but that could be established via cron jobs
  • automatically delete files: as with the previous bullet point. Also see Remove all “deleted” files in Git
  • command line. GUI not needed: Yes. It uses a VCS as backend (Git, Bazar, Mercurial), so you simply use their CLI. Stuff not managed by those VCS, etckeeper deals with itself using hooks.
  • open source: it is (and it seems you already contributed there).

You wouldn't need much shell-scripting for that. As per your definition ("One commit per day is enough"), all that would be needed were a task in /etc/cron.daily running git add *; git commit (plus something for the delete) – and catering the .gitignore, if needed.

  • This tool focuses on the /etc directory. A general purpose solution is what I need. But nevertheless, thank you for your answer.
    – guettli
    May 17, 2018 at 6:54
  • @guettli so the -d parameter would just specify a different /etc directory (i.e. a directory with the same structure as /etc)? That's what its main purpose is (to work on a copy e.g. from a different machine). But to me it was not clear whether this could not be "abused" to deal with "any" directory. Did you try? I had no time yet to do so myself… // PS: You might wish to accept your answer to show the issue has an "acceptable solution". If something better turns up, you always can "switch the mark" ;)
    – Izzy
    May 17, 2018 at 9:13
  • Yes, there is the -d option. It could be used. But there is one issue I did not talk about up to now: I looked into some shell scripts of etckeeper. It is ugly shell scripting, which I don't trust. Up to now I think the my answer is better. But I don't want to accept my own answer. Especially since I did not tried it up to now.
    – guettli
    May 17, 2018 at 9:31
  • @guettli don't be too shy once you've tried and confirmed it. Accepting your self-answer is perfectly fine.
    – Izzy
    May 17, 2018 at 16:51

A partial answer is fswatch. It will monitor a directory tree and produce a line when something changes.

508 ==> fswatch -t -x tt2
Mon Apr 30 06:04:16 2018/Volumes/User_Raid/sherwood/Webwork/sftf/tt2/Trees/
PlatformSpecific Updated AttributeModified IsFile

On certain platforms you will also get notices for parent directories. The virtue of fswatch is that it saves having to check every file. Output can be logged to a file, or piped to another process, or execute a program for each event. (I use it to rebuild web pages when source template has changed.)

  • I updated my answer: I am not looking for inotify (event handling if file was changed) or something like this.
    – guettli
    Apr 30, 2018 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.