Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

From: Duy Nguyen <pclouds@gmail.com>
Date: Feb 13, 2018, 09:57 UTC
Message-ID: <CACsJy8BWh=e6_Sz20djd5ixxm_Pwa43OHNzXrBatm14k0P+qxQ@mail.gmail.com>
In-Reply-To: <d1371a6c-2b30-515a-372e-4fea9bc09c43@gmail.com>

On Tue, Feb 13, 2018 at 12:57 AM, Ben Peart <peartben@gmail.com> wrote:

Show 14 quoted lines

>> Another case that could touches a lot of directories over time is
>> switch trees (e.g. "git checkout master" then "checkout next" or worse
>> "checkout v1.0").
>
>
> You're example above makes me wonder if you understand what my patch is
> doing.  If the index is flagged as dirty for _any_ reason, the entire index
> is written to disk with the latest information - including the updated
> untracked cache and all other extensions.  So in your checkout examples
> above, the index will still get written to disk with the updated untracked
> cache extension.  There would be zero change in behavior or performance.
> The _only_ time the index is not written to disk after my patch is if there
> were no other changes to the index.  In my experience, that is only status
> calls.

The untracked cache is updated and does get written down, but it's not "repaired" unless you have called read_directory() before the index is written. Though paths that hit untracked_cache_invalidate_path() will continue on slow path until you call read_directory() and write down. I don't think "git checkout" calls read_directory. There are some commands, like "git add", that update the index and call read_directory() at the same time. So yes I was wrong, the untracked cache can be repaired sometimes, not never repaired.

We do try to improve performance at "git checkout" and a couple other "slow" commands though (e.g. repair cache tree), perhaps we can do the same for untracked cache. Though the cost of updating untracked cache is potentially much higher than cache tree.

-- 
Duy