On Sun, Feb 11, 2018 at 9:44 PM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > 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? There's test-dump-untracked-cache that will give you all the data. >From then on, you may need to dig in the code a bit to see how that data should be processed. There's no obfuscation support in that command, unfortunately, so you can't just send me the dump. But if you could limit it to a few "blocks" related to the error messages, then manual obfuscation should not take that much time (either that or just add obfuscation in test-dump-untracked-cache.c, it's probably easier task; or I can do this for you) >>> 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. One question (I wasn't clear from your previous mail). Does "git status" always report the same errors when run multiple times, or does it just report once, then next "git status" is silent? I suppose it's the former case.. -- Duy
