On Wed, Mar 20, 2013 at 02:36:32AM -0400, Andrew Rodland wrote:
> While investigating this StackOverflow question:
> I found that fetch-pack.c uses ST_MTIME_NSEC outside of the protection
> of #ifdef USE_NSEC. This results in a broken build if
> !defined(USE_NSEC) && !defined(NO_NSEC) and the target system doesn't
> happen to be recent glibc.
Right; the point of NO_NSEC is to tell git that your libc does not have
those fields. If it's not set, then it is a bug in your config.mak (or
in the autoconf script, if you are using it).
That being said, I really don't see the point of having both USE_NSEC
and NO_NSEC. If you do not set USE_NSEC (which most people do not; it is
off by default), what is the point of not setting NO_NSEC? As far as I
can tell, it means we will copy stat information out "struct st" into
the index, but we will not actually _use_ it for anything.
Should there just be a single option USE_NSEC that defaults to off? And
if it is not set, we do not even bother caring whether libc provides
nsec fields, since we are not going to use them for anything (i.e., we
just do the equivalent of NO_NSEC now).
Which I think is the direction you are proposing with your patches
below, but the rationale should be "why bother requiring users to use
the NO_NSEC knob explicitly when we know we do not care about its value
But maybe there is some subtle reason I'm missing for having the two
options separate. Or maybe it's just a historical accident that we ended
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