On Sat, Feb 10 2018, Duy Nguyen jotted: > On Sat, Feb 10, 2018 at 1:37 AM, Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> wrote: >> >> On Thu, Feb 01 2018, Junio C. Hamano jotted: >> >>> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits >>> - dir.c: stop ignoring opendir() error in open_cached_dir() >>> - update-index doc: note a fixed bug in the untracked cache >>> - dir.c: fix missing dir invalidation in untracked code >>> - dir.c: avoid stat() in valid_cached_dir() >>> - status: add a failing test showing a core.untrackedCache bug >>> >>> Some bugs around "untracked cache" feature have been fixed. >>> >>> Will merge to 'next'. >> >> I think you / Nguyễn may not have seen my >> <87d11omi2o.fsf@xxxxxxxxxxxxxxxxxxx> >> (https://public-inbox.org/git/87d11omi2o.fsf@xxxxxxxxxxxxxxxxxxx/) > > I have. But since you wrote "I haven't found... yet", I assumed you > were still on it. You didn't give me much info to follow anyway. Haven't had time to dig further, sorry, and won't be able to share the repository. Is there some UC inspection command that can be run on the relevant path / other thing that'll be indicative of what went wrong? >> As noted there I think it's best to proceed without the "dir.c: stop >> ignoring opendir[...]" patch. >> >> It's going to be a bad regression in 2.17 if it ends up spewing pagefuls >> of warnings in previously working repos if the UC is on. > > "previously working" is a strong word when opendir() starts to > complain. Sure we can suppress/ignore the error messages but I don't > think it's a healthy attitude. Unreported bugs can't be fixed. I mean that for the user it returned the right "git status" info and didn't print errors, but yeah, the index may have been in some internally funny state. > We could perhaps stop reporting after we have printed like ... 5 lines > or so? That keeps the noise level down a bit and probably still give > enough indicator to at least repair the cache.
