Mark Levedahl <mleved...@gmail.com> writes:
> Unlike the results on the fast Win7 laptop, the above show
> statistically significant slow down from the fast_lstat approach. I'm
> just not seeing a case for the special case handling, and of course
> Junio has already voted with his preference of removing the special
> case stuff as well.
Please don't take what I said as any "vote" in this thread. I do
not have a first-hand data to back anything up.
I was primarily trying to see my understanding of the consensus of
the thread was correct. If we can do without s/lstat/fast_lstat/
almost everywhere in the codebase, of course, I would be happier, as
it would give us one less thing to worry about.
If the assumptions like "they were declining minority and only lose
population over time", "it is easy for them to revert the removal
and keep going", and "removal will not hurt them too much in the
first place, only a few hundred milliseconds", that might trump the
longer-term maintainability issue, and we may end up having to carry
that win32 stat implementation a bit longer until these users all
switch to Cygwin 1.7, but judging from the "cvs binary seems to be
built incorrectly" incident the other day, it might be the case some
users still hesitate to update, fearing that 1.7 series may not be
solid enough, perhaps?
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