Re: [PATCH] Ensure that commit/status don't stat all files when core.ignoreStat = true
- From
Marius Storm-Olsen <marius@trolltech.com>
- Date
- May 27, 2008, 20:21 UTC
- Message-ID
- <483C6D60.7090705@trolltech.com>
- In-Reply-To
- <7v7idf1pqy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano said the following on 27.05.2008 22:00:
Show 6 quoted lines
> Marius Storm-Olsen <marius@trolltech.com> writes: > The description for core.ignorestat in Documentation/config.txt is quite > bogus. That single bit does _not_ determine globally if we lstat(2) or > not. The description in Documentation/git-update-index.txt about it (look > for the section "Using assume unchanged bit") accurately describes what it > is meant to do. The rules are:
Aha! Thanks for the detailed explanation of core.ignoreStat. Given your description, the patch is certainly bogus.
Show 11 quoted lines
> Would it be sufficient for what you are trying to do if you changed that
> test to something like this?
>
> /*
> * CE_VALID means the user promised us that the change to
> * the work tree does not matter and told us not to worry.
> */
> if (!ignore_valid && (ce->ce_flags & CE_VALID)) {
> ce_mark_uptodate(ce);
> return ce;
> }I'll give it a shot tomorrow, to see how it affects my use-cases. Thanks.
>> diff --git a/wt-status.c b/wt-status.c >> index a44c543..72db466 100644 >> --- a/wt-status.c >> +++ b/wt-status.c
...
Show 8 quoted lines
> The core.ignorestat variable does not have anything to do with showing > untracked files. It is about "do we mark the added path as CE_VALID, > meaning that we do not have to lstat(2) them?" IOW, it is about tracked > files. > > While it might be useful in certain workflows to ignore untracked files, I > do not think it is a good idea to overload such an unrelated meaning to > the variable.
Indeed. I'll resend a new patch tomorrow with a new variable which will only affect the stat'ing of untracked files, if you think that's reasonable. IMO, we certainly need a way of avoiding to stat the whole filetree on commits and status. I mean, that's what you have the -u option for, right? :-) In any case, an opt-in feature, of course.
Thanks for checking the patch!
-- .marius