Hacker News Reader

Comment by spacemanaki | Hacker News Reader

How well does git handle non-text files like .psd and .ai files?

According to "Mercurial: The Definitive Guide" by Bryan O'Sullivan [1], it might make sense to use Subversion if you are collaborating with others on said binary files:

> Because Subversion doesn't store revision history on the client, it is well suited to managing projects that deal with lots of large, opaque binary files. If you check in fifty revisions to an incompressible 10MB file, Subversion's client-side space usage stays constant The space used by any distributed SCM will grow rapidly in proportion to the number of revisions, because the differences between each revision are large.

> In addition, it's often difficult or, more usually, impossible to merge different versions of a binary file. Subversion's ability to let a user lock a file, so that they temporarily have the exclusive right to commit changes to it, can be a significant advantage to a project where binary files are widely used.

[1]: http://hgbook.red-bean.com/read/how-did-we-get-here.html

I have a git repo that seems to do fine handling binary files of 1-200 megabytes that regularly update.

The downside is that the repo grows by that much every time I update the file. The upside is that I get a version history if I need to back out to an older version!

Also, you can't diff or merge them.

Thats not gits fault. It would need to know how the programm that preduced the file does updates or some professor somewere has to figure it out on bitlevel.

With the push in the design community to create some sort of replacement for psd comps, I could see a new file type becoming accepted.

The problem is that web design inevitably ends up in pixels, and I will always have to move to that level to tweak, anathema to version control.

It can handle whatever you put into it, but obviously won't be able to diff them.

Can you provide your own diff-programs for different binary formats?

Of course.

Git knows about three things; blobs, trees, and commits. A blob is a collection of bytes. It is stored on disk as a file containing the bytes named after the sha1 hash of the bytes. A tree is a set of mappings from name to a blob or a tree, allowing you to represent collections of blobs like they exist on disk. Finally, the commit object is some metadata (author, committer, date, message, etc.) and a tree object. Add some shell or Perl scripts on top of this, and you have Git.

So if you can write a simple shell script, you can make git do whatever you want it to do.

(That's why git seems so "messy" from an implementation standpoint, it's a bunch of shell and perl scripts that do random things. Darcs and Mercurial have a slightly more complicated model, and hence everything has to happen "inside". This results in a cleaner looking interface, but a lot less hackability.)

Reply on news.ycombinator.com