{"thread":{"id":"19969","subject":"git-gui is slow to display a large number of changed/new files","startedAt":"2009-06-29T21:19:54Z","lastAt":"2009-06-30T14:47:27Z","messageCount":2,"participants":["Dan Zwell","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"117180","messageId":"4A492FFA.5030703@zwell.net","threadId":"19969","inReplyTo":null,"subject":"git-gui is slow to display a large number of changed/new files","fromName":"Dan Zwell","fromEmail":"dzwell@zwell.net","sentAt":"2009-06-29T21:19:54Z","receivedAt":"2009-06-29T21:19:54Z","isPatch":false,"sender":{"key":"dzwell@zwell.net","avatar":null},"body":"Hello,\n\nI was recently working on a project with tens of thousands of generated \nfiles. The generated directory was not intended to be tracked by git, \nbut I had forgotten to add it to .gitignore. When I tried to use \ngit-gui, it seemed to hang for about a minute. The problem is that \ncreating the icons in the \"staged changes\" and \"unstaged changes\" \nwindows is very slow. This data is redisplayed after several operations, \nand the lag makes git-gui unusable.\n\nIs this behavior worth changing? I doubt the scenario I encountered is a \ncommon one. However, I have written a patch to display at most 5000 \nchanged/new files, warning the user that the list has been truncated. If \nthis is a worthy change, I can submit the patch--I can also change it so \nthat the maximum number of displayed files is taken from git's \nconfiguration.\n\nThanks\n-Daniel\n"},{"id":"117236","messageId":"81b0412b0906300747id528b76ue48d0bf1ba3709fe@mail.gmail.com","threadId":"19969","inReplyTo":"4A492FFA.5030703@zwell.net","subject":"Re: git-gui is slow to display a large number of changed/new files","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-06-30T14:47:27Z","receivedAt":"2009-06-30T14:47:27Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2009/6/29 Dan Zwell <dzwell@zwell.net>:\n> Is this behavior worth changing? I doubt the scenario I encountered is a\n> common one.\n\nIt happens. There are imported repositories, and things like CVS/SVN/Perforce\nforce people to do giant commits. So yes, it definitely is worth looking into.\n\n> ... However, I have written a patch to display at most 5000\n> changed/new files, warning the user that the list has been truncated. If\n> this is a worthy change, I can submit the patch--I can also change it so\n> that the maximum number of displayed files is taken from git's\n> configuration.\n\nEven 5000 is insane, so that would be a good start, for sure.\n\nPaul Mackerras is gitk's maintainer, remember to put him on Cc:\n"}]}