On Thu, Sep 13, 2007 at 06:54:02PM -0700, Linus Torvalds wrote: > It would be interesting to hear what the situation is that makes > run_status be too expensive. Doing a "git status" on the kernel tree > currently takes something like 0.3 seconds for me when the directory and > stat information cached - and while it's obviously going to be a *lot* > slower if there's IO involved, that IO is basically required for doing the > up-to-date check anyway. > > So maybe somebody already described the situation that was slow already, > but if so, can we get a repeat of that description? I ran into a painfully slow "runstatus" a few weeks ago that made committing more difficult, though you may consider the repo to be pathological. The packfile is about 1.1G, split over about 850 files (it's photos and short movies). I did a large amount of moving of existing files, along with some edits of exif tags (changing a few hundred bytes at most at the beginning of each 1M-ish file). Running git-runstatus chugged for a few minutes, and I don't think I ever actually finished a run. I assumed the rename detection was at fault (when I show that commit diff, I also get a huge slowdown). So the problem isn't get being stupidly slow, it's just that I have a pathological repo (and a pathological set of changes) where the cost of showing the commit template isn't worth it. I think Dmitry's approach of adding a "don't show the template" option to git-commit is the right way of handling this. Changing the behavior all the time would affect non-pathological cases. I suppose you could let git-runstatus chug for a few seconds, and then if it hasn't finished kill it and show a less intensive status summary; that just seems hack-ish and wrong to me, though. -Peff - 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
