On Mon, Mar 10, 2014 at 6:28 PM, demerphq <demer...@gmail.com> wrote: > I had the impression, and I would not be surprised if they had the > impression that the git development community is relatively > unconcerned about performance issues on larger repositories. > > There have been other reports, which are difficult to keep track of > without a bug tracking system, but the ones I know of are: > > Poor performance of git status with large number of excluded files and > large repositories.
I thought this has been improved lately.. I think we could do better still, but my wip is nowhere ready for anybody's eyes. > Poor performance, and breakage, on repositories with very large > numbers of files in them. index v5 and sparse checkout should help a bit. The ultimate solution, though, is narrow clone that's nowhere near finishing. Well, if you need all files present in worktree, then narrow clone does not help either.. On the same line, poor performance on repos with a lot of very large files also. Junio's split-blob series was a start, but no one picked it up, so I guess your impression was right. > (Rebase for instance will break if you rebase a commit that contains a *lot* > of files.) Interesting. I guess it hits shell's limitations? Roughly how many files to break it? > Poor performance in protocol layer (and other places) with repos with > large numbers of refs. (Maybe this is fixed, not sure.) Ah.. no it's not. It's being stirred up again though, in both protocol and ref backend. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
