Re: [PATCH 0/6] inotify support
On Thu, Feb 20, 2014 at 3:35 AM, Shawn Pearce wrote: > 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? I did look briefly through its readme before but there were a few off-factors like CLA, JSON.. that made me go away. I agree that reusing the same daemon would save us maintenance code and buy the stability (and maybe sharing some inotify handles for users that use both git and hg). I'll need to have a closer look at it and compare with what I've got, now that I have a better picture of how things should work. -- Duy -- 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
Re: [PATCH 0/6] inotify support
On Sun, Jan 12, 2014 at 3:03 AM, Nguyễn Thái Ngọc Duy 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
[PATCH 0/6] inotify support
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 Nguyễn Thái Ngọc Duy (6): read-cache: save trailing sha-1 read-cache: new extension to mark what file is watched read-cache: connect to file watcher read-cache: get "updated" path list from file watcher read-cache: ask file watcher to watch files file-watcher: support inotify .gitignore | 1 + Makefile | 1 + cache.h | 4 + config.mak.uname | 1 + file-watcher.c (new) | 329 +++ git-compat-util.h| 5 + pkt-line.c | 2 +- pkt-line.h | 2 + read-cache.c | 280 ++- wrapper.c| 27 + 10 files changed, 645 insertions(+), 7 deletions(-) create mode 100644 file-watcher.c -- 1.8.5.2.240.g8478abd -- 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