On Sat, Apr 30, 2016 at 1:46 AM, David Turner <dturner@xxxxxxxxxxxxxxxx> wrote: > On Thu, 2016-04-28 at 11:58 -0700, Junio C Hamano wrote: >> David Turner <dturner@xxxxxxxxxxxxxxxx> writes: >> >> > From: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> >> > ... >> > The biggest gain is not having to verify the trailing SHA-1, which >> > takes lots of time especially on large index files. But this also >> > opens doors for further optimiztions: >> >> optimizAtion >> >> > Git can poke the daemon via unix domain sockets to tell it to >> > refresh >> > the index cache, or to keep it alive some more minutes. It can't >> > give >> > any real index data directly to the daemon. Real data goes to disk >> > first, then the daemon reads and verifies it from there. Poking >> > only >> > happens for $GIT_DIR/index, not temporary index files. >> >> Is this limited to "poking", or the helper daemon is not involved in >> codepaths that handle temporary index at all? It makes sense if it >> is the latter, and it doesn't if it were the former, but it is >> unclear in this paragraph. > > It is in fact the latter. Will clarify. The intention is so. The execution is less than perfect. On the server side, the index-helper only concerns itself with .git/index only. Good. On the client side, is_main_index() is used to detect if it's $GIT_DIR/index. It checks if the given index_state pointer points to the_index and if so assumes that it is the main index. That is not true when read_cache_from() is used with something other than git_index_file() as argument. Which is exactly what builtin/commit.c does in prepare_index(). .git/index.lock gets passed in instead. read-cache.c may "poke" or "refresh" (probably should rename these to "read" and "write") because is_main_index() incorrectly returns true. Luckily it will soon find out index-helper does not prepare shm for this particular index file and fall back to reading from disk. We waste some context switches though. -- Duy -- 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