"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > These are probably pretty cheap on all but the largest repositories. I > was worried we were enumerating all refs or all history or something > like that. > >> ui_do_rescan changes the focus to the first diff. It is executed when you >> press F5 or choose Rescan from the menu. do_rescan does not do that. >> >> Resetting to first diff on focus change will get annoying when you are in >> the middle of looking at some other file. do_rescan just updates the >> software state without changing what file you are looking at or where in >> that file you are looking at. > > Yeah, this definitely seems like the right move. "Right move" in the sense that it would try not to change what is being shown too much. Rescan will still not be without cost, so it will be annoying if it happens when the user did not make any change. And it is annoying even more, if the user did make change in another window. You may make a change perhaps from the command line, write a short e-mail about it to let others know in your MUA, and then switch the focus back to git-gui to continue working. Refreshing upon git-gui getting focus is no better than manually pressing F5 or whatever at that point. It is too late at that point for spending extra cycles without being asked without getting annoying to the user. The right time to spend cycles (in the background) in the above sample sequence is immediately after you made a change and switch to your MUA---while you are typing a few paragraphs, you would not mind git-gui spending seconds to repaint. So probably a more productive use of our time, if we were to futz with git-gui, would be to figure out how git-gui can have an background idle process that notices a change in the repository and refreshes but only when you are *not* interacting with it (if it does things while you are interacting with it, it would become annoying and distracting), I would guess. Just when you come back is the worst, and the most annoying, time to auto-refresh.
