Re: Bug in index-helper/watchman?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 14, 2016 at 5:21 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
>> On Thu, Jul 14, 2016 at 12:11 AM, Ben Peart <peartben@xxxxxxxxx> wrote:
>>> I’ve been chasing down an issue where it looks like the untracked cache
>>> logic doesn’t work correctly in the index-helper/watchman patch series.
>>> It’s also entirely possible that I’m just missing something so feel free to
>>> correct my misconceptions.
>>>
>>>
>>>
>>> Ultimately, it appears that none of the untracked cache directories are
>>> getting flagged as invalid from the data in the watchman extension.  I
>>> believe this is happening because untracked->root doesn’t get initialized
>>> until validate_untracked_cache is called from read_directory.  This causes
>>> all calls to lookup_untracked to return NULL so the dir->valid flag is never
>>> set to zero in mark_untracked_invalid.

No, validate_untracked_cache does not do anything fancy in there to
make UC initialized. It may invalidate UC further though.

But you did spot a problem. What if UC extension is loaded _after_
watchman one? Then index->untracked_cache would have nothing in there
and invalidation is no-op when we do it (at watchmain ext loading
time). We can't control extension loading order (technically we can,
but other git implementations may do it differently). So, maybe we
should do the invalidation after _all_ index extensions have been
loaded.

Maybe we can do it in validate_untracked_cache? We already store the
path list in the_index.untracked->invalid_untracked.
validate_untracked_cache has all info it needs.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]