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

> On Tue, Feb 6, 2018 at 7:27 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Tue, Feb 6, 2018 at 8:48 AM, Ben Peart <peartben@gmail.com> wrote:
>>> With the new behavior, making a change in dir1/, then calling status would
>>> update the dir1/ untracked cache entry but not write it out. On the next
>>> status, git would detect the change in dir1/ again and update the untracked
>>
>> Thing only missing piece here I would add is, this dir1/ detection is
>> done by watchman. We have to contact watchman and ask the set of
>> changed paths since $TIME where $TIME is the last time we updated
>> untracked cache and invalidate those paths in core. Then it should
>> work correctly. I checked the watchman query in the fsmonitor hook and
>> I think it's correct so far.
>
> No I think I'm wrong. And worse, I think the interaction between FSNM
> and UNTR extension is broken. This is partly from me guessing how
> fsmonitor works so I may be double-wrong.
>
> UNTR extension is supposed to cover the untracked state at timestamp
> $X. Where $X is stored in FSNM extension. Correct?
>
> When fsmonitor is used and read_directory() is executed (at timestamp
> $Y), we ask watchman "what's new on worktree since $X?"). We get the
> list, we invalidate relevant directories so we can see new untracked
> entries (or lack of old untracked entries). We write FSNM with
> timestamp $Y down. We may or may not write UNTR down because of this
> patch, but let's suppose we do. All is good. UNTR now records the
> state at $Y. FSNM says $Y. This is how it works (when there's no bugs)
>
> UNTR extension is only updated when read_directory() is called. It
> does not always happen. FSNM is updated all the time (almost at every

> git command since most of them needs to read index, many write it
> down) with new timestamp. Suppose FSNM now records timestamp $Z, UNTR
> still records the state at $Y because in the last index update,
> read_directory() is not executed. 4 files have been added between $Y
> and $Z. When we ask watchman "what's new since $Z?" we will not see
> those files, so we don't invalidate relevant directories and
> read_directory() will not see those files.