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
> 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=222278

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

Reply via email to