Junio C Hamano <gitster@xxxxxxxxx> writes: > Karsten Blees <karsten.blees@xxxxxxxxx> writes: > >> However, AFAIK inotify doesn't work recursively, so the daemon >> would at least have to track the directory structure to be able to >> register / unregister inotify handlers as directories come and go. > > Yes, and you would need one inotify per directory but you do not > have an infinite supply of outstanding inotify watch (wasn't the > limit like 8k per a single uid or something?), so the daemon must be > prepared to say "I'll watch this, that and that directories, but the > consumers should check other directories themselves." Those are tunable limits though. For example I run this silly hack https://github.com/trast/watch with the shell snippets to be able to quickly cd a shell to where something recently happened. I am able to watch most of my "working set" even under default limits, which here (opensuse tumbleweed, kernel 3.8.x, x86_64) are $ cat /proc/sys/fs/inotify/max_user_watches 65536 $ cat /proc/sys/fs/inotify/max_user_instances 128 I'm not sure if other distros impose tighter limits by default, but as it stands you're not very likely to hit the 65k watches limit in any given repo. It seems more likely that you might hit the 128 instances limit if we go with a design that uses one daemon per repo, if you run a script that accesses many repos. For example, in an android tree I have lying around, $ repo list | wc -l 297 That alone might indicate it would be a good idea to have one "global" git-agent that starts on demand, rather than a per-repo daemon. Otherwise we'd have to find a way to discover "old" daemons and tell them to quit when we hit max_user_instances. -- Thomas Rast trast@{inf,student}.ethz.ch -- 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