> I don't imagine myself finding that very useful but if it's cheap and we can > filter out the stuff in '.gitignore' along with the '.git' folder, then I > don't see why not. The litmus test here should probably be that the CPU(s) > remain idle while GitX is in the background. If that's not doable then it > might be best to throttle it such that it only checks in 2 or 3 times a > second or so. > > The other issue I see here is that the refresh itself might prove annoying > if it's kicking off before all the changes have propagated. So maybe > something where we wait for events and then hold off on refreshing until > things are idle again. Mind you I haven't played with or looked at this code > at all. Just thinking out loud.
I agree on both accounts, also given the way the fsevents patch could interfere with for example big rebases. One way to limit this might be to look into the .git dir to see if another process has a lock on the git index, and waiting with a refresh until that look has disappeared (or the user gives an explicit refresh).
