threads / discuss / 19969

git-gui is slow to display a large number of changed/new files

Subject: git-gui is slow to display a large number of changed/new files

## tl;dr

2 messages between Jun 29, 2009 and Jun 30, 2009.

replies: 1people: 2as markdown or json

Dan Zwell· Jun 29, 2009, 21:19 UTC · lore

Hello,

I was recently working on a project with tens of thousands of generated files. The generated directory was not intended to be tracked by git, but I had forgotten to add it to .gitignore. When I tried to use git-gui, it seemed to hang for about a minute. The problem is that creating the icons in the "staged changes" and "unstaged changes" windows is very slow. This data is redisplayed after several operations, and the lag makes git-gui unusable.

Is this behavior worth changing? I doubt the scenario I encountered is a common one. However, I have written a patch to display at most 5000 changed/new files, warning the user that the list has been truncated. If this is a worthy change, I can submit the patch--I can also change it so that the maximum number of displayed files is taken from git's configuration.

Thanks -Daniel

Alex Riesen· Jun 30, 2009, 14:47 UTC · re: Dan Zwell · lore

Re: git-gui is slow to display a large number of changed/new files

2009/6/29 Dan Zwell <dzwell@zwell.net>:

> Is this behavior worth changing? I doubt the scenario I encountered is a
> common one.

It happens. There are imported repositories, and things like CVS/SVN/Perforce force people to do giant commits. So yes, it definitely is worth looking into.

Show 5 quoted lines

> ... However, I have written a patch to display at most 5000
> changed/new files, warning the user that the list has been truncated. If
> this is a worthy change, I can submit the patch--I can also change it so
> that the maximum number of displayed files is taken from git's
> configuration.

Even 5000 is insane, so that would be a good start, for sure.

Paul Mackerras is gitk's maintainer, remember to put him on Cc: