----- Ursprungligt meddelande -----
> Robin Rosenberg <robin.rosenb...@dewire.com> 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

(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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to