On Mon, Sep 14, 2009 at 9:14 PM, Dave Grijalva <[email protected]> wrote: > > The issue with autorefreshing the commit view seems to be that if you ask it > to refresh while it's still refreshing, it freaks out. Seems like a good > opportunity to introduce a queue. There are a few other options that will > help reduce the issue, but the only thing that will eliminate it is to make > sure calling reload a bunch of times can't break stuff.
Yeah, it's annoying. If we want to make sure we're not still refreshing, we'd need some kind of system to keep track of when refreshes are done, which sounds a bit hard when all the refresh stuff is asynchronous. > - we can increase the interval between refreshes That's probably a good idea. > - we can try use gitignore to not refresh if only ignored files have been > modified (this one might be tricky, but would unnecessary reduce reloads > during builds, etc) That's a good idea we can do when we enable it in the commit view. > Seems like it might be safer to only enable it for the history view to > start, since there will likely be more engineering involved in getting the > commit view to be stable. Yes, I agree. One thing that might be acceptable in the meantime is checking whether the .git/index changes, and then only refresh the index changes (without calling git-update-index). That should be lockless and thus relatively harmless.
