On Mar 9, 2010, at 7:11 PM, Dave Grijalva wrote: > The linux kernel is in git. It's HUGE.
I keep forgetting about that. > I could also be totally wrong, but it seems to me that using the OS's > built-in features is going to give us the best bang for the buck. I'm > totally open to any other ideas. I'm not saying that fsevents is the wrong way to go, I think it's the right way. But I had some issues with PBGitRepositoryWatcher and decided to make things work without it now then go back to it later. One of the problems that I had is that the callback can get called multiple times (with max 32 paths/events each). If there are two changes in the .git directory that end up in two different callbacks then the notification for a git directory change is sent out twice right in a row. I have not used the FSEvents API before, but if I understand them then if the repo watcher would check FSEventsGetCurrentEventId against the last event in the callback's list then cache the current PBGitRepositoryWatcherEventType until the last callback is sent it could then send one notification. (I think, maybe? :) Also if anything in the .git directory changes it causes the revision list to update the commits even if no commits changed. I think breaking up the PBGitRepositoryWatcherEventTypeGitDirectory type into several is necessary. For example check if the only changes are in the .git/packed-refs file or anywhere in .git/refs/*, then that would cause the repository to just reload the refs (fast) and not all the commits (slow). There are some other cool stuff we could do, like have PBGitConfig cache the contents of the config file. This would be useful because I check to see if the current branch has a remote in order to update the UI, and not having to ask git to read a file would be much faster. I never did look into what was causing the problems with the index. To sum up, my problem is that the PBGitRepositoryWatcherEventTypeGitDirectory event type is currently too broad and happens too often. --Nathan http://brotherbard.com/
