Re: [git-users] worlds slowest git repo- what to do?

From: Duy Nguyen <pclouds@gmail.com>
Date: May 16, 2014, 10:13 UTC
Message-ID: <CACsJy8CmiW88tNavRphZa_uMU=jVUCQE6cw5+t2AYnf5dDmcsQ@mail.gmail.com>
In-Reply-To: <06A2490FC9BC4461A39B982D3C7C85F7@PhilipOakley>

On Fri, May 16, 2014 at 2:06 AM, Philip Oakley <philipoakley@iee.org> wrote:

Show 12 quoted lines

> From: "John Fisher" <fishook2033@gmail.com>
>>
>> I assert based on one piece of evidence ( a post from a facebook dev) that
>> I now have the worlds biggest and slowest git
>> repository, and I am not a happy guy. I used to have the worlds biggest
>> CVS repository, but CVS can't handle multi-G
>> sized files. So I moved the repo to git, because we are using that for our
>> new projects.
>>
>> goal:
>> keep 150 G of files (mostly binary) from tiny sized to over 8G in a
>> version-control system.

I think your best bet so far is git-annex (or maybe bup) for dealing with huge files. I plan on resurrecting Junio's split-blob series to make core git handle huge files better, but there's no eta on that. The problem here is about file size, not the number of files, or history depth, right?

>> problem:
>> git is absurdly slow, think hours, on fast hardware.

Probably known issues. But some elaboration would be nice (e.g. what operation is slow, how slow, some more detail characteristics of the repo..) in case new problems pop up.

-- 
Duy