5 ms·

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

by spacemanaki 16y ago

ams1 16y ago
It can handle whatever you put into it, but obviously won't be able to diff them.
- eru 16y ago
  Can you provide your own diff-programs for different binary formats?
  - jrockway 16y ago
    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.)
stellar678 16y ago
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!
- ryanpetrich 16y ago
  Also, you can't diff or merge them.
  - nickik 16y ago
    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.
    - sudont 16y ago
      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.
erikano 16y ago
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 http://hgbook.red-bean.com/read/how-did-we-get-here.html

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

ams1 16y ago

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

eru 16y ago
Can you provide your own diff-programs for different binary formats?
- jrockway 16y ago
  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.)

stellar678 16y ago

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!

ryanpetrich 16y ago
Also, you can't diff or merge them.
- nickik 16y ago
  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.
  - sudont 16y ago
    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.

erikano 16y ago

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 http://hgbook.red-bean.com/read/how-did-we-get-here.html