Junio C Hamano <[email protected]> writes:
> Ramkumar Ramachandra <[email protected]> writes:
>
>> ... Will Git ever
>> consider using inotify on Linux? What is the downside?
>
> I think this has come up from time to time, but my understanding is
> that nobody thought things through to find a good layer in the
> codebase to interface to an external daemon that listens to inotify
> events yet. It is not something like "somebody decreed that we
> would never consider because of such and such downsides." We are
> not there yet.
I checked read-cache.c and preload-index.c code. To get the
discussion rolling, I think something like the outline below may be
a good starting point and a feasible weekend hack for somebody
competent:
* At the beginning of preload_index(), instead of spawning the
worker thread and doing the lstat() check ourselves, we open a
socket to our daemon (see below) that watches this repository and
make a request for lstat update. The request will contain:
- The SHA1 checksum of the index file we just read (to ensure
that we and our daemon share the same baseline to
communicate); and
- the pathspec data.
Our daemon, if it already has a fresh data available, will give
us a list of <path, lstat result>. Our main process runs a loop
that is equivalent to what preload_thread() runs but uses the
lstat() data we obtained from the daemon. If our daemon says it
does not have a fresh data (or somehow our daemon is dead), we do
the work ourselves.
* Our daemon watches the index file and the working tree, and
waits for the above consumer. First it reads the index (and
remembers what it read), and whenever an inotify event comes,
does the lstat() and remembers the result. It never writes
to the index, and does not hold the index lock. Whenever the
index file changes, it needs to reload the index, and discard
lstat() data it already has for paths that are lost from the
updated index.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
