Re: Why Git is so fast
- From
Andreas Ericsson <ae@op5.se>
- Date
- May 4, 2009, 08:01 UTC
- Message-ID
- <49FEA0F5.2050800@op5.se>
- In-Reply-To
- <81b0412b0904301216j7ef73870y775cf6d89b5aa71e@mail.gmail.com>
Alex Riesen wrote:
Show 15 quoted lines
> 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.