13

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?

Dema
  • 6,867
  • 11
  • 40
  • 48
  • Why don't you want the content to be tracked specifically? – Sedat Kapanoglu Jan 31 '11 at 11:46
  • 3
    I don't know what @Dema's reasons are, but git-annex describes two use cases for this: http://git-annex.branchable.com/ –  Apr 21 '11 at 22:26
  • This is a dupe of http://stackoverflow.com/questions/540535/managing-large-binary-files-with-git – dbn Feb 26 '13 at 22:04
  • Since April 2015, you can consider git-lts. See [my answer below](http://stackoverflow.com/a/29530871/6309) – VonC Apr 09 '15 at 05:59

5 Answers5

13

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

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

Community
  • 1
  • 1
11

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.

CB Bailey
  • 755,051
  • 104
  • 632
  • 656
  • 4
    I disagree that it's the wrong tool; git is also a user space file system with many "plumbing" commands available so it can be used in novel ways beyond version control of content –  May 13 '11 at 06:44
  • I'm facing a similar problem... do you have any suggestions to the "right" tool for tracking many binary files? – eykanal Jan 06 '12 at 14:30
  • -1 for toolbear. Git is not for tracking binary files (in its straight use )... and what is that "user space file system" ???? – voila Dec 14 '13 at 02:48
2

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.

Dana the Sane
  • 14,762
  • 8
  • 58
  • 80
1

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.

https://cloud.githubusercontent.com/assets/1319791/7051226/c4570828-ddf4-11e4-87eb-8fc165e5ece4.gif

  • 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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

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.

Daniel Fanjul
  • 3,493
  • 3
  • 26
  • 29