[georgemcbay]

Every time you make a change to a binary file, git will make a copy of the entire thing and attempt to compress it (despite the fact that it may already be compressed as part of the file format and won't compress any further). And because of the distributed nature of git this means each client is going to have who-knows-how-many perhaps barely different versions of each binary asset, which could be megabytes to hundreds of megabytes in length per version and woe be unto anyone who has to clone the repository for the first time when coming into the project (be prepared to wait hours, maybe days).

There are various git methodologies and projects (eg. git-annex) aimed at working around this but by default git just wasn't designed to deal with big repos full of big files.

[stevelaz]

OK, I get it. The hashing would become slow on each file (especially large ones). And given that git is designed to give you the whole repo history, yes, cloning would be slow with repos with a lot of history.

It seems like 2 of the main reasons Perforce works better with binary files is that when you sync, you only get the version you're requesting, thus resulting in faster downloads and there's an option to disable compression.

According to their website: http://www.perforce.com/perforce/doc.current/manuals/p4guide... Binary files are stored compressed as well. (I assume that there's an option to disable this)

Thanks for the response and information.

[georgemcbay]

Yes that's exactly correct. On the client-side P4 basically only really cares about the current version (or whatever branched/changelisted revision you are working with) which for projects with a lot of files (especially binary files) will be an incredibly smaller set of data than the full history. git is fully distributed with all of the pros and cons that come with that.