On Thu, Nov 26, 2015 at 6:53 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Thu, Nov 26, 2015 at 6:21 AM, Christian Couder > <christian.couder@xxxxxxxxx> wrote: >> I am wondering why you didn't make it by default run the mtime checks >> when a kernel change is detected. Maybe that would be better than >> disabling itself. > > It takes about 10 seconds to go through the mtime check. Imagine you > have to wait 10s for some random "git status".. Plus I didn't want to > do anything fancy. I browsed through the commits that added the --untracked-cache and tried to find the original mailing list discussion, but I couldn't find the reason for why the default interface for enabling it is doing these exhaustive tests. Maybe I'm missing some really common breakage with st_mtime on some system, but having a feature the user explicitly enables turn itself off and doing FS-testing that takes 10 seconds when it's enabled seems like the wrong default to me. We don't do it with core.fileMode, core.ignorecase or core.trustctime or core.symlinks. Do we really need to be treating this differently? If that's a "no" then the default interface to this could be much simpler. Rather than being a change you apply to .git/index (going away if you nuke it etc.) it could just be a config option like the rest. -- 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