Mauritzio, I don't entirely understand your reply, and I'm not sure you 
clearly understood my question. Your reference to "work on just the 
sources" makes sense for software development, where there are non-binary 
source files and binary object files. In our case that distinction doesn't 
exist. In some cases, like Visio or Omnigraffle files, the "source files" 
themselves are binary, or effectively binary (e.g. generated XML). In other 
cases, like screen shots, there are no "source files" at all.

The alternate ways of dealing with binaries might work for us, and I'd like 
to look into them if so. However, any solution we consider has to scale 
well over the amount of activity that occurs, as well as the amount of data 
that is stored.

For example: a project that is graphics-intensive (but not unusually so) 
might contain a dozen non-binary files and a hundred binary files, changing 
in about equal proportions. A viable solution must let us handle the binary 
files without performing a lot of additional manual steps. If a new user 
mistakenly omits any extra steps required for binary files, the resulting 
mess must be one that can be cleaned up without an inordinate cost in time 
and resources!

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to