Jeff King <p...@peff.net> writes:
>> But, taking a step back, I think it is a bad idea to have an unreliable
>> stat() masquerading as a real stat(). If we want to allow the use of an
>> unreliable stat for certain purposes, let's have two stat() interfaces:
>> * the true stat() (in this case I guess cygwin's slow-but-correct
>> * some fast_but_maybe_unreliable_stat(), which would map to stat() on
>> most platforms but might map to the Windows stat() on cygwin when so
> Yeah, that makes sense to me. I don't have a particular opinion on which
> way to go, as I do not use cygwin at all (and on most platforms, the
> two stat interfaces would just both call stat()).
> I will leave it up to Cygwin folks whether they want to do something
> like my patch as a band-aid while working up the two-stat() solution.
I think in the longer term two-stat solution is a good thing.
0117c2f0 (Make core.sharedRepository work under cygwin 1.7,
2013-03-23) introduced get_st_mode_bits() to work around another
glitch in the fast-but-cheating-and-unreliable replacement, which
we may be able to revert once it is done.
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