Re: Why Git is so fast

[Andreas Ericsson <ae@op5.se>]

Alex Riesen wrote:
> 2009/4/30 Nicolas Pitre <nico@cam.org>:
>> Yet, this point is misleading because when people gives to Git the
>> reputation of being faster, this is certainly from comparison of
>> operations performed on the same source tree.  Who cares about scenarios
>> for which the tool was not designed?  Those "enterprise configuration
>> management repositories" are not what Git was designed for indeed, but
> 
> Especially when no sane developer will put in his repository the toolchain
> (pre-compiled. For all supported platforms!), all the supporting tools
> (like grep,
> find, etc.Pre-compiled _and_ source), the in-house framework (pre-compiled
> and source, again), firmware (pre-compiled and put in the repository weekly),
> and operating system code (pre-compiled, with firmware-specific drivers,
> updated, you guessed it, weekly), and well, there is the project itself (Java or
> C++, and documentation in .doc and .xls)...

Well, git could actually handle that just fine if the toolchain was in a
submodule or even in a separate repository that developers never had to
worry about. Then you'd design a little tool that said "re-create build 8149"
and it would pull the tools used to do that, and the code and the artwork,
and then set to work. It'd be an overnight (or over-weekend) job, but no
man-hours would be spent on it. That's how I'd do it anyways, probably
with the "build" repository as a master repo with "tools", "code" and
"artwork" as submodules to it.

> Now, what kind of self-hating idiot will design a system for that kind of abuse?

Noone, naturally, but one might design a system where each folder
in the repository root is considered a repository in its own right,
and then get that more or less for free.

The problem with git for such scenarios is that you have to think
*before* creating the repository, or play silly buggers when importing
which makes it hard to see how the pieces fit together afterwards.

A tool that could take a repository from a different scm, create a
master repository and several submodule repositories from it would
probably solve many of the issues gaming companies have if they want
to switch to using git. Not least because it would open their eyes
to how that sort of separation can be done in git, and why it's
useful. The binary repos can then turn off delta-compression (and
zlib compression) for all its blobs using a .gitattributes file,
and things would be several orders of magnitudes faster.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
 http://nordicmeetonnagios.op5.org/

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.