Thread (10 messages) flat view 10 messages, 4 authors, 2016-06-15

Re: [RFC/PATCH] config: add core.trustmtime

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2016-06-15 23:07:20

On Thu, Nov 26, 2015 at 6:53 PM, Duy Nguyen [off-list ref] wrote:
On Thu, Nov 26, 2015 at 6:21 AM, Christian Couder
[off-list ref] wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help