In addition to requiring you to mark when you want the changes to be remembered, you also have to deploy these changes to a different location that will serve as your backup. Since the git backups are stored on the same hard drive as the data, a disk failure would destroy all your images anyway! A secondary hard drive (either local or remote) needs to be set up to transfer the images from your current environment to the backup environment. Since commits and pushes are different operations, for every change you need to do TWO commands to save the changes reliably (A hook can be set up to only require one command, but this requires more programming knowledge).

Ultimately, the real problem with backups systems is we don’t expect the unexpected. As a result, we usually don’t think about backing up until it is too late. In this way, Time Machine works great due to its transparency and hands-off approach.

If I wanted to have a finer grain backup system, I would create a daemon that would commit changes and push them to two different environments (local second hard drive and remote server) automatically. The daemon can know when a file is modified using a pipe to DTrace. This way, every time I save a change, the daemon commits and pushes the changes to two different destinations. This would leave me with a reliable, transparent, and finely grained version control system.

Notice that if your computer has irreparably damaged due to an electrical storm, flood, fire, theft, etc… Time-Machine might be gone alongside your main hard drive. By backing up on a remote server, this prevents geographically localized incidents from ruining your data.

Looking at the rSync doc, it seems like it does not really keep an history of the files, it is used to sync the file system.
Also, GIT is distributed, there is no ‘master’ data repository, every clone can be used as a source, or be used to update the rest of the network.
This last feature is quite cool when you work with multiple computers and you can replicate in every direction.
Also the ability to create multiple versions of a whole project (not just a file) is key.

Maybe I was not clear but once DMGed, you dont recycle the card, you keep it until the data is backuped on another drive. This way, you have the files on two separate media.

Why would you use Git over rsync?

Think about it… maybe a CF card has some sort of glitch, maybe a bad sector (not sure about terminology here) or whatever. That card gets archived to a dmg that then has a problem opening. Cards should never be recycled in the field, but what if, by mistake, it happened?

This is obviously a worst case scenario, but it is technology we’re talking about here. Stranger things can happen.