delta/git.git/compat, branch ly/mktree-using-strbuf

Typofixes outside documentation area

2010-02-04T05:28:17+00:00

    begining -> beginning
    canonicalizations -> canonicalization
    comand -> command
    dewrapping -> unwrapping
    dirtyness -> dirtiness
    DISCLAMER -> DISCLAIMER
    explicitely -> explicitly
    feeded -> fed
    impiled -> implied
    madatory -> mandatory
    mimick -> mimic
    preceeding -> preceding
    reqeuest -> request
    substition -> substitution

Signed-off-by: Junio C Hamano

Implement pthread_cond_broadcast on Windows

2010-01-30T03:42:40+00:00

See http://www.cse.wustl.edu/~schmidt/win32-cv-1.html, section "The
SignalObjectAndWait solution". But note that this implementation does not
use SignalObjectAndWait (which is needed to achieve fairness, but we do
not need fairness).

Note that our implementations of pthread_cond_broadcast and
pthread_cond_signal require that they are invoked with the mutex held that
is used in the pthread_cond_wait calls.

Signed-off-by: Johannes Sixt 
Signed-off-by: Junio C Hamano

msvc: Fix a compiler warning due to an incorrect pointer cast

2010-01-23T00:15:16+00:00

Signed-off-by: Ramsay Jones 
Acked-by: Sebastian Schuberth 
Signed-off-by: Junio C Hamano

msvc: Fix an "unrecognized option" linker warning

2010-01-23T00:15:14+00:00

Having recently added support for building git-imap-send on
Windows, we now link against OpenSSL libraries, and the linker
issues the following warning:

    warning LNK4044: unrecognized option '/lssl'; ignored

In order to suppress the warning, we change the msvc linker
script to translate an '-lssl' parameter to the ssleay32.lib
library.

Note that the linker script was already including ssleay32.lib
(along with libeay32.lib) as part of the translation of the
'-lcrypto' library parameter.  However, libeay32.dll does not
depend on ssleay32.dll and can be used stand-alone, so we remove
ssleay32.lib from the '-lcrypto' translation.

The dependence of ssleay32.dll on libeay32.dll is represented in
the Makefile by the NEEDS_CRYPTO_WITH_SSL build variable.

Also, add the corresponding change to the buildsystem generator.

Signed-off-by: Ramsay Jones 
Acked-by: Sebastian Schuberth 
Signed-off-by: Junio C Hamano

Do not use date.c:tm_to_time_t() from compat/mingw.c

2010-01-17T02:16:13+00:00

To implement gettimeofday(), a broken-down UTC time was requested from the
system using GetSystemTime(), then tm_to_time_t() was used to convert it
to a time_t because it does not look at the current timezone, which
mktime() would do.

Use GetSystemTimeAsFileTime() and a different conversion path to avoid this
back-reference from the compatibility layer to the generic code.

Signed-off-by: Johannes Sixt 
Signed-off-by: Junio C Hamano

MSVC: Windows-native implementation for subset of Pthreads API

2010-01-17T02:16:06+00:00

This patch implements native to Windows subset of pthreads API used by Git.
It allows to remove Pthreads for Win32 dependency for MSVC, msysgit and
Cygwin.

[J6t: If the MinGW build was built as part of the msysgit build
environment, then threading was already enabled because the
pthreads-win32 package is available in msysgit. With this patch, we can now
enable threaded code unconditionally.]

Signed-off-by: Andrzej K. Haczewski 
Signed-off-by: Johannes Sixt 
Signed-off-by: Junio C Hamano

MSVC: Fix an "incompatible pointer types" compiler warning

2010-01-17T00:43:55+00:00

In particular, the following warning is issued while compiling
compat/msvc.c:

    ...mingw.c(223) : warning C4133: 'function' : incompatible \
types - from '_stati64 *' to '_stat64 *'

which relates to a call of _fstati64() in the mingw_fstat()
function definition.

This is caused by various layers of macro magic and attempts to
avoid macro redefinition compiler warnings. For example, the call
to _fstati64() mentioned above is actually a call to _fstat64(),
and expects a pointer to a struct _stat64 rather than the struct
_stati64 which is passed to mingw_fstat().

The definition of struct _stati64 given in compat/msvc.h had the
same "shape" as the definition of struct _stat64, so the call to
_fstat64() does not actually cause any runtime errors, but the
structure types are indeed incompatible.

In order to avoid the compiler warning, we add declarations for the
mingw_lstat() and mingw_fstat() functions and supporting macros to
msvc.h, suppressing the corresponding declarations in mingw.h, so
that we can use the appropriate structure type (and function) names
from the msvc headers.

Signed-off-by: Ramsay Jones 
Signed-off-by: Johannes Sixt 
Signed-off-by: Junio C Hamano

Windows: avoid the "dup dance" when spawning a child process

2010-01-17T00:43:53+00:00

When stdin, stdout, or stderr must be redirected for a child process that
on Windows is spawned using one of the spawn() functions of Microsoft's
C runtime, then there is no choice other than to

1. make a backup copy of fd 0,1,2 with dup
2. dup2 the redirection source fd into 0,1,2
3. spawn
4. dup2 the backup back into 0,1,2
5. close the backup copy and the redirection source

We used this idiom as well -- but we are not using the spawn() functions
anymore!

Instead, we have our own implementation. We had hardcoded that stdin,
stdout, and stderr of the child process were inherited from the parent's
fds 0, 1, and 2. But we can actually specify any fd.

With this patch, the fds to inherit are passed from start_command()'s
WIN32 section to our spawn implementation. This way, we can avoid the
backup copies of the fds.

The backup copies were a bug waiting to surface: The OS handles underlying
the dup()ed fds were inherited by the child process (but were not
associated with a file descriptor in the child). Consequently, the file or
pipe represented by the OS handle remained open even after the backup copy
was closed in the parent process until the child exited.

Since our implementation of pipe() creates non-inheritable OS handles, we
still dup() file descriptors in start_command() because dup() happens to
create inheritable duplicates. (A nice side effect is that the fd cleanup
in start_command is the same for Windows and Unix and remains unchanged.)

Signed-off-by: Johannes Sixt 
Signed-off-by: Junio C Hamano

Windows: simplify the pipe(2) implementation

2010-01-17T00:43:52+00:00

Our implementation of pipe() must create non-inheritable handles for the
reason that when a child process is started, there is no opportunity to
close the unneeded pipe ends in the child (on POSIX this is done between
fork() and exec()).

Previously, we used the _pipe() function provided by Microsoft's C runtime
(which creates inheritable handles) and then turned the handles into
non-inheritable handles using the DuplicateHandle() API.

Simplify the procedure by using the CreatePipe() API, which can create
non-inheritable handles right from the beginning.

Signed-off-by: Johannes Sixt 
Signed-off-by: Junio C Hamano

Windows: boost startup by avoiding a static dependency on shell32.dll

2010-01-17T00:43:51+00:00

This DLL is only needed to invoke the browser in a "git help" call. By
looking up the only function that we need at runtime, we can avoid the
startup costs of this DLL.

DLL usage can be profiled with Microsoft's Dependency Walker. For example,
a call to "git diff-files" loaded

before:  19 DLLs
after:    9 DLLs

As a result, the runtime of 'make -j2 test' went down from 16:00min
to 12:40min on one of my boxes.

Signed-off-by: Johannes Sixt 
Signed-off-by: Junio C Hamano