On Sun, Jan 12, 2014 at 3:03 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
It's been 37 weeks since Robert Zeh's attempt to bring inotify support
to Git [1] and unless I missed some mails, no updates since. So here's
another attempt with my preferred approach (can't help it, playing
with your own ideas is more fun than improving other people's code)
To compare to Robert's approach:
- This one uses UNIX datagram socket. If I read its man page right,
unix socket respects the containing directory's permission. Which
means on normal repos, only the user process can access. On shared
repos, multiple users can access it. This should work on Mac.
Windows will need a different transport.
- The daemon is dumb. It passes the paths around and that's it.
lstat() is done by git. If I design it right, there's should not be
any race conditions that make git miss file updates.
- CE_VALID is reused to avoid mass changes (granted there's other
neat ways as well). I quite like the idea of machine-controlled
CE_VALID.
inotify support has the potential of reducing syscalls in
read_directory() as well. I wrote about using lstat() to reduce
readdir() a while back, if that's implemented then inotify will fit in
nicely.
This is just a proof of concept. I'm sure I haven't handled all error
cases very well. The first five patches show the protocol and git
side's changes. The last one fills inotify in.
[1] http://thread.gmane.org/gmane.comp.version-control.git/215820/focus=78
Why a new daemon? Why don't we reuse the stable
https://github.com/facebook/watchman project Facebook built to make
Hg's status system fast?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
