> -----Original Message----- > From: Junio C Hamano > Sent: Monday, January 07, 2013 2:29 AM > > Jason Pyeron writes: > > [administrivia: please never cull CC list when you respond to a > message on this list without a good reason]
Apologies, I just have 4 copies of every message and was trying to save other that pain. > > >> circumvent the Cygwin API (and by extension, Cygwin project goals). > >> > >> So, perhaps a better path forward is to disable / remove the > >> above code by default. (Those wanting a native Win32 git > >> should just use the native > >> Win32 git). > > > > Or a make option... > > It already is a runtime option, isn't it? > > I do not have much stake in this personally, but IIRC, the (l)stat > workaround was back then found to make Cygwin version from "unusably > slow" to "slow but torelable", as our POSIX-y codebase assumes that > lstat is fairly efficient, which Cygwin cannot satisify because it Is there already a set of test cases I can run to validate that this is still true? > has call many win32 calls to collect bits that we do not even look > at, in order to give faithful emulation. It does place extra > maintenance burden (e.g. conditional compilation depending on the > header file the particular version of Cygwin installation the user > has at hand) on us, but as long as it works, the ugly hack is fairly There seems to be only 2 valid use cases here, with regards to cygwin. 1. Do it the normal posix way, and dont hack it up. 2. For speed reasons, merge in native windows/non-posix functions. I would not care about the user's cygwin version because the cygwin supporters won't either. In both cases assume the latest cygwin libraries. If there is a specific user with a use case for an older version of cygwin libraries then we can cross that bridge when (if) we arrive at it. > isolated and I do not see a reason to unconditionally rip it out, > especially if the reasoning behind such move is on "All programs > that run in Cygwin environment has to be POSIX only and must not use > Win32 API directly, even in a controlled way." I presently do not care if it stays or goes. But if someone were to bring this to the cygwin mailing list it would be a headache to deal with the "hacked" way. They would likely be more receptive to increasing the efficiency of the lstat than other approaches. > > It is a completely different matter if the direct win32 calls we > make, bypassing (l)stat emulation, somehow change the internal state > of win32 resources Cygwin controls and violates the invariants > Cygwin API implemenation expects, breaking later calls to it. I > do not know that is the case here, but I doubt it. I agree, it is not going to break anything here. Those libraries are just a way of presenting the Windows API without using Microsoft files and making it easier to wrap the POSIX apis to it.
smime.p7s
Description: S/MIME cryptographic signature
