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 >> implementation) >> >> * 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 >> configured. > > 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
