On 2/7/2018 5:59 AM, Duy Nguyen wrote:
On Tue, Feb 6, 2018 at 7:55 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
On Tue, Feb 6, 2018 at 7:27 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
On Tue, Feb 6, 2018 at 8:48 AM, Ben Peart <peartben@xxxxxxxxx> 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
I was indeed doubly wrong. When FSMN is read, it does make calls to
invalidate stuff in untracked cache data structure. If the index is
written down (with updated FSMN extension and timestamp) then the UNTR
extension, which is generated from in-core untracked data structure,
also reflects the damages by the changed paths so next time even if
those changed paths are not reported again (between $Y and $Z below),
it's fine.
All is good in the world again :)
Thank you for looking into this closely. It's always good to have
someone else examine the logic to make sure there aren't errors that
were missed. Sorry my responses have been slow, my day job has had me
busy lately.
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.
