----- Ursprungligt meddelande -----
> Robin Rosenberg <[email protected]> writes:
>
> > diff --git a/read-cache.c b/read-cache.c
> > index fda78bc..f7fe15d 100644
> > --- a/read-cache.c
> > +++ b/read-cache.c
> > @@ -197,8 +197,9 @@ static int ce_match_stat_basic(struct
> > cache_entry *ce, struct stat *st)
> > }
> > if (ce->ce_mtime.sec != (unsigned int)st->st_mtime)
> > changed |= MTIME_CHANGED;
> > - if (trust_ctime && ce->ce_ctime.sec != (unsigned
> > int)st->st_ctime)
> > - changed |= CTIME_CHANGED;
> > + if ((trust_ctime ||
> > ((check_nonzero_stat&CHECK_NONZERO_STAT_CTIME) &&
> > ce->ce_ctime.sec)))
>
> One SP is required on each side of a binary operator; please have
> one after check_nonzero_stat and after the & after it.
>
> I wonder if we should lose the trust_ctime variable and use this
> check_nonzero_stat bitset exclusively, provided that this were a
> good direction to go?
Semantically they're somewhat different. My flags are for ignoring
a value when it's not used as indicated by the value zero, while
trustctime is for ignoring untrustworthy, non-zero, values.
>From 1ce4790bf5e:
A new configuration variable 'core.trustctime' is introduced to
allow ignoring st_ctime information when checking if paths
in the working tree has changed, because there are situations where
it produces too much false positives. Like when file system crawlers
keep changing it when scanning and using the ctime for marking scanned
files.
(your second mail)
>Also I am getting these:
>
>config.c: In function 'git_default_core_config':
>config.c:571: error: passing argument 1 of 'git_config_string' from
>incompatible pointer type
>config.c:540: note: expected 'const char **' but argument is of type 'char **'
>config.c:573: error: passing argument 1 of 'strtok' discards qualifiers from
>pointer target type
Different compilers have different defaults. I'm on OS X (mountain lion), or am
I missing
something? I do get a warning. Am I allowed to modify the value, like strtok
does? Seems I
missed the opportunity to use the copy rather then the original value.
Another thing that I noticed, is that I probably wanto to be able to filter on
the precision
of timestamps. Again, this i JGit-related. Current JGit has milliseconds
precision (max), whereas
Git has down to nanosecond precision in timestamps. Newer JGits may get
nanoseconds timestamps too,
but on current Linux versions JGit gets only integral seconds regardless of
file system.
Would the names, milli, micro, nano be good for ignoring the tail when zero, or
n1..n9 (obviously
n2 would be ok too). nN = ignore all but first N nsec digits if they are zero)?
-- robin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
