On OS X there are document files that aren't really files. They are directories with a metadata attribute that says they are logically files. For example, the popular outliner OmniOutliner stores it outlines that way. An OmniOutliner "document" consists of a directory that contains a "contents.xml" file that has the outline, plus any other files that you've attached to the outline. This poses a bit of a problem for VCS systems, because from the user point of view, the directory is opaque. Content is added or removed by the programs that edit the document, not directly by the user, and so On Mercurial, which I've been evaluating for a couple of months as a replacement for Subversion at work, this can be handled easily with a pre-commit hook: [hooks] pre-commit = mdfind -0 -onlyin . "kMDItemContentTypeTree = 'com.apple.package'" | xargs -0 hg addremove That mdfind command finds things marked as com.apple.package. For each, the hook adds to the commit any new files found in the package, and removes anything that's been deleted. I'm done evaluating Mercurial and now it's Git's turn. I'm liking it so far, but am stumped as to how to do the equivalent of the above Mercurial hook. Does this sound about right? Use a pre-commit hook that checks all the files that have been staged, and see if any of them are in a directory that is a package. If so, it needs to add any changes from those directories that are not staged, and add any untracked files from those directories. This means that if the user makes a change to a document, and wants it to be committed, the user has to stage at least one file from the package directory. It also means that the user can't partially stage on of these documents, but I think that's an acceptable limitation. Thanks! -- --Tim Smith -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html