Joshua Redstone wrote: > The test repo has 4 million commits, linear history and about 1.3 million > files. Have you tried separating these two factors, to see how badly each is affecting performance? If the number of commits is the problem (seems likely for git blame at least), a shallow clone would avoid that overhead. I think that git often writes .git/index inneficiently when staging files (though your `git add` is pretty fast) and committing. It rewrites the whole file to .git/index.lck and the renames it over .git/index at the end. I have code that keeps a journal of changes to avoid rewriting the index repeatedly, but it's application specific. Fixing git to write the index more intelligently is something I'd like to see. Hint for git status: `git status .` in a smaller subdirectory will be much faster than the default that stats everything. -- see shy jo
Attachment:
signature.asc
Description: Digital signature