Re: git status reads too many files

From: Lasse Makholm <lasse.makholm@gmail.com>
Date: Mar 21, 2011, 20:39 UTC
Message-ID: <AANLkTikPL7Dx5AphGnd1TVAyLNgNh2WVd__Yom134VXb@mail.gmail.com>
In-Reply-To: <7vipvcs9xt.fsf@alter.siamese.dyndns.org>

On 21 March 2011 17:41, Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

> Lasse Makholm <lasse.makholm@gmail.com> writes:
>
>> This persistent across multiple runs of git status:
>>
>> $ strace -o /tmp/trace2 git status
>> # On branch there
>> nothing to commit (working directory clean)
>> $ grep ^open /tmp/trace2 | wc -l
>> 414
>> $
>>
>> ...until the index is touched:
>>
>> $ touch .git/index
>
> Don't do this; you are breaking the racy-git protection.

Yeah, I know, I was just proving a point... git reset (--hard?) HEAD would achieve the same thing...

Show 5 quoted lines

> I think we opportunistically update the .git/index file in "git status" to
> refresh the stat bits (but we don't error out when we cannot write a new
> index, as you may be only browsing somebody else's repository with only a
> read access to it).  It probably should be just the matter of adding a bit
> of logic to notice that your index is racily clean.

I figured as much... My original thought of checkout ensuring an index newer than any working file is stupid, of course, for a multitude of reasons -- one of which is that the "next" timestamp may be a full 2 seconds away...

> Let me cook something real quick.

Sweet, thanks...

-- 
/Lasse