Alex Riesen <raa.lkml@xxxxxxxxx> wrote: > Shawn O. Pearce, Wed, Aug 12, 2009 16:43:45 +0200: > > Dan Zwell <dzwell@xxxxxxxxx> wrote: > > > When there is a large number of new or modified files, > > > "display_all_files" takes a long time, and git-gui appears to > > > hang. This change limits the number of files that are displayed. > > > This limit can be set as gui.maxfilesdisplayed, and is > > > 5000 by default. > > > > > > A warning is shown when the list of files is truncated. > > > > Thanks, applied. > > But now, when I really think about the change, it looks useless. > What has the _number_ of files has to do with the files you actually > have to handle? As the sorting of the file list cannot be changed (and > it wouldn't be a big help anyway), you have no chance to get to your > file if it happens to be past the limit! > > Wouldn't a pathname/glob filter in the command-line (or file/path > selection dialog) to limit the scope be more appropriate and useful? > And have the file list reading to happen in background, as gitk does? Good point. I suspect the problem wasn't so much with Tcl doing the list processing as it was with Tk actually creating the underlying icons and stuff for each file name. But with the list clipped, you are right, you are basically SOL. You can't do much beyond dropping back to the CLI and using the CLI tools. IMHO, if we aren't going to handle 20k file names, we should at least punt and tell the user we aren't going to handle 20k file names, rather than just play Outlook wannabe and lockup the entire UI until the user gets bored and kill -9's us. So this patch is better than nothing, it at least lets the user know we have given up on them. -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html