Re: [RFC/PATCH 0/1] cygwin: Remove the Win32 l/stat() functions

Johannes Sixt [off-list ref] writes:

Some context: This is about a patch by Ramsay that removes the
"schizophrenic lstat" hack for Cygwin. Junio, can you please queue that
patch in pu?

Sure.  Thanks.

On 2013-06-25 23.18, Junio C Hamano wrote:

Johannes Sixt [off-list ref] writes:

quoted

Some context: This is about a patch by Ramsay that removes the
"schizophrenic lstat" hack for Cygwin. Junio, can you please queue that
patch in pu?

Sure.  Thanks.

First of all,
thanks for the work.

Here some "benchmark" results, 
(The test run of the test suite did the same amout of time).

But:
git status -uno in real life takes double the time,
git 1.8.3 compared against "pu with the vanilla l/stat"
   
    1 second ->  2 seconds on linux kernel
0.2 seconds -> 0.4 seconds on git.git 

Do we have any known problems with the current implementation ?
Does speed matter ?

One vote to keep the special cygwin functions.
(And have a look how to improve the core.filemode)

/Torsten

Torsten Bögershausen wrote:

On 2013-06-25 23.18, Junio C Hamano wrote:

quoted

Johannes Sixt [off-list ref] writes:

quoted

Some context: This is about a patch by Ramsay that removes the
"schizophrenic lstat" hack for Cygwin. Junio, can you please queue that
patch in pu?

Sure.  Thanks.

First of all,
thanks for the work.

Here some "benchmark" results, 
(The test run of the test suite did the same amout of time).

The test suite runs noticeably faster for me.

But:
git status -uno in real life takes double the time,
git 1.8.3 compared against "pu with the vanilla l/stat"
   
    1 second ->  2 seconds on linux kernel
0.2 seconds -> 0.4 seconds on git.git 

Hmm, OK, I guess I will have to try something else. Sigh :(

Do we have any known problems with the current implementation ?

Yes. The next branch is currently broken. (see reply to Junio)

Does speed matter ?

One vote to keep the special cygwin functions.
(And have a look how to improve the core.filemode)

I don't understand this (parenthetical) comment; could you
elaborate on this.

ATB,
Ramsay Jones

On 06/26/2013 10:19 AM, Torsten Bögershausen wrote:

On 2013-06-25 23.18, Junio C Hamano wrote:

quoted

Johannes Sixt [off-list ref] writes:

quoted

Some context: This is about a patch by Ramsay that removes the
"schizophrenic lstat" hack for Cygwin. Junio, can you please queue that
patch in pu?

Sure.  Thanks.

First of all,
thanks for the work.

Here some "benchmark" results,
(The test run of the test suite did the same amout of time).

But:
git status -uno in real life takes double the time,
git 1.8.3 compared against "pu with the vanilla l/stat"
    
     1 second ->  2 seconds on linux kernel
0.2 seconds -> 0.4 seconds on git.git

Do we have any known problems with the current implementation ?
Does speed matter ?

One vote to keep the special cygwin functions.
(And have a look how to improve the core.filemode)

/Torsten

There have been threads on the cygwin mailing lists for at least a 
decade looking to speed up cygwin's posix stat / lstat (and fork). If 
improvement were merely difficult, it would have been done long ago. As 
git cares about things like execute bits, file / repository permissions, 
and soft links, whatever stat / lstat git uses needs to fully support 
those under cygwin, either by using what cygwin provides or providing a 
complete replacement. Note my other reply - with Ramsay's patch I can 
complete the test suite (except for t0008.sh that has a known hang) 
while without it I find the test suite randomly (unrepeatable) hangs in 
many tests. So, this stat/lstat replacement is at least implicated in 
current troubles.

Mark

On 2013-06-26 23.54, Ramsay Jones wrote:

Torsten Bögershausen wrote:

quoted

On 2013-06-25 23.18, Junio C Hamano wrote:

quoted

Johannes Sixt [off-list ref] writes:

quoted

Some context: This is about a patch by Ramsay that removes the
"schizophrenic lstat" hack for Cygwin. Junio, can you please queue that
patch in pu?

Sure.  Thanks.

First of all,
thanks for the work.

Here some "benchmark" results, 
(The test run of the test suite did the same amout of time).

The test suite runs noticeably faster for me.

quoted

But:
git status -uno in real life takes double the time,
git 1.8.3 compared against "pu with the vanilla l/stat"
   
    1 second ->  2 seconds on linux kernel
0.2 seconds -> 0.4 seconds on git.git 

Hmm, OK, I guess I will have to try something else. Sigh :(

quoted

Do we have any known problems with the current implementation ?

Yes. The next branch is currently broken. (see reply to Junio)

quoted

Does speed matter ?

One vote to keep the special cygwin functions.
(And have a look how to improve the core.filemode)

I don't understand this (parenthetical) comment; could you
elaborate on this.

ATB,
Ramsay Jones

This is probably wrong information:
I had in mind that cygwin sets core.filemode=false,
which is quite annoying when exchanging .sh files with linux.
But that seems to be wrong, a quick test shows that core.filemode=true.
Sorry for confusion.

Torsten Bögershausen wrote:
[ ... ]

quoted

quoted

(And have a look how to improve the core.filemode)

I don't understand this (parenthetical) comment; could you
elaborate on this.

This is probably wrong information:
I had in mind that cygwin sets core.filemode=false,

It does, see commit c869753e ("Force core.filemode to false on
Cygwin", 30-12-2006).

which is quite annoying when exchanging .sh files with linux.

Indeed, I used to build git with NO_TRUSTABLE_FILEMODE reset so
that I wouldn't have to edit the config file by hand after a
git-clone or git-init.

But that seems to be wrong, a quick test shows that core.filemode=true.

Hmm, it shouldn't - confused!

Sorry for confusion.

ATB
Ramsay Jones