Efficient storage of binary files in a git reposit

Question

I would like to have a git repository that consists mainly of binary files.

I need to keep track of the changed, added and removed files to the repository, but I don't want for git to version the content of the files themselves.

In other words, I just need for git to keep track of changes (change log), but not the content.

Is this even possible with git?

Should I be using something else for this?

Answer 1

If you don't want to store the bins, than you could use a binary diff tool on the files, then commit the output into version control. Any text change log entries can then be entered in to the commit message.

Answer 2

Mined from @Tobu's answer to this related question:

To version and propagate binary files without actually storing them in git, try git-annex.

Answer 3

Maybe I don't understand your question but what if you store in a text file the timestamp of all files? Then, you could store in version control only that file, and let your VCS diff the different versions of it.

Answer 4

but I don't want for git to version the content of the files themselves.

That is exactly what Git Large File Storage (LFS) does (by GitHub, April 2015).

The project is git-lfs (see git-lfs.github.com) and a tested with server supporting it: lfs-test-server:
You can store metadata only in the git repo, and the large file elsewhere.

• Large files are synced separately to a configurable Git LFS server over HTTPS, so you are not limited in where you push your Git repository.

• Large files are only synced from the server when they are checked out, so your local repository doesn't carry the weight of every version of every file when it is not needed.

• The meta data stored in Git is extensible for future use. It currently includes a hash of the contents of the file, and the file size so clients can display a progress bar while downloading or opt out of a large download.

Answer 5

git is a content tracker, so if you don't want to track content it sounds like it's the wrong tool for the job. I'm not sure exactly how you would track changes to files without tracking their content, though.