Re: [PATCH] Brown paper bag fix for MinGW 64-bit stat

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] Brown paper bag fix for MinGW 64-bit stat

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:46:21

Johannes Schindelin [off-list ref] writes:
When overriding the identifier "stat" so that "struct stat" will be
substituted with "struct _stati64" everywhere, I tried to fix the calls
to the _function_ stat(), too, but I forgot to change the earlier
attempt "stat64" to "_stati64" there.

So, the stat() calls were overridden by calls to _stati64() instead.

Unfortunately, there is a function _stati64() so that I missed that
calls to stat() were not actually overridden by calls to mingw_lstat(),
but t4200-rerere.sh showed the error.

Signed-off-by: Johannes Schindelin <redacted>
Since this is a fix-up to a new on 'master', I've applied the patch
myself, but how would we want to handle MinGW related patches in general?

My preference is to have somebody I can rely on receiving Acked forwards
from (or pulling from).

Re: [PATCH] Brown paper bag fix for MinGW 64-bit stat

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:46:21

Hi,

On Sat, 7 Mar 2009, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
When overriding the identifier "stat" so that "struct stat" will be
substituted with "struct _stati64" everywhere, I tried to fix the calls
to the _function_ stat(), too, but I forgot to change the earlier
attempt "stat64" to "_stati64" there.

So, the stat() calls were overridden by calls to _stati64() instead.

Unfortunately, there is a function _stati64() so that I missed that
calls to stat() were not actually overridden by calls to mingw_lstat(),
but t4200-rerere.sh showed the error.

Signed-off-by: Johannes Schindelin <redacted>
Since this is a fix-up to a new on 'master', I've applied the patch
myself, but how would we want to handle MinGW related patches in general?

My preference is to have somebody I can rely on receiving Acked forwards
from (or pulling from).
My preference is to keep the tried and tested mingw.git maintainer... ;-)

Note: IMHO Windows support is really at most beta quality; I would prefer 
only those using it who can fix bugs themselves, or have the means to make 
others fix the bugs.

So technically, we do not need such a strict and rigid process as for 
git.git itself, which is blessed with hundreds of contributors, due to 
which is really is ready for the end-user.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help