Re: [PATCH 01/02/RFC] implement a stat cache

On Monday 21 April 2008, Dmitry Potapov wrote:

On Sun, Apr 20, 2008 at 04:07:35PM -0700, Linus Torvalds wrote:

quoted

Junio, what was the logic for that whole "has_symlink_leading_path()"
thing? I forget. Whatever, it's broken.

===
commit f859c846e90b385c7ef873df22403529208ade50
Author: Junio C Hamano [off-list ref]
Date:   Fri May 11 22:11:07 2007 -0700

[snip snip]

===

And there are some cases where stat() on path is desirable:
http://www.spinics.net/lists/git/msg63988.html

So while stat information for regular files is cached in the index,
stat information for directories is not cached, and that appears to
be wrong. Maybe, Lucano's cache makes sense if it stores only stat
information for directories.

IIRC, some time ago, an otherwise reasonable patch for .gitignore was
rejected just because it would drive the number calls to lstat() up as
these calls on directories are not cached in the index.

Pardon me for butting in (and I'm honestly NOT trying to start a flamewar),
but I'm wondering if this could be solved by tracking directories in the
index. AFAICS it would:

- Help bring the number of lstat() calls down (since we can cache the
  lstat() results for directories like we currently do for regular files)

- More easily detect complicated cases like "add across symlinks" (see
  Junio's email at the spinics.net link above)

- (less important) When discussing empty directory support several months
  ago, ISTR one of the biggest hurdles being that directories were not
  tracked in the index


I don't know much about how the index is implemented (few do, I think), so
if there is a glaringly obvious reason why tracking directories in the
index is a bad idea, please enlighten me.


...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net