path: root/compat/mingw.c
AgeCommit message (Collapse)Author
2019-10-30Merge branch 'js/mingw-needs-hiding-fix'Junio C Hamano
Fix for a (rather old) buffer-overrun bug. * js/mingw-needs-hiding-fix: mingw: avoid a buffer overrun in `needs_hiding()`
2019-10-28mingw: avoid a buffer overrun in `needs_hiding()`Johannes Schindelin
When this function is passed a path with a trailing slash, it runs right over the end of that path. Let's fix this. Co-authored-by: Alexandr Miloslavskiy <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-10-15Merge branch 'js/azure-pipelines-msvc'Junio C Hamano
CI updates. * js/azure-pipelines-msvc: ci: also build and test with MS Visual Studio on Azure Pipelines ci: really use shallow clones on Azure Pipelines tests: let --immediate and --write-junit-xml play well together test-tool run-command: learn to run (parts of) the testsuite vcxproj: include more generated files vcxproj: only copy `git-remote-http.exe` once it was built msvc: work around a bug in GetEnvironmentVariable() msvc: handle DEVELOPER=1 msvc: ignore some libraries when linking compat/win32/path-utils.h: add #include guards winansi: use FLEX_ARRAY to avoid compiler warning msvc: avoid using minus operator on unsigned types push: do not pretend to return `int` from `die_push_simple()`
2019-10-09Merge branch 'js/diff-rename-force-stable-sort'Junio C Hamano
The rename detection logic sorts a list of rename source candidates by similarity to pick the best candidate, which means that a tie between sources with the same similarity is broken by the original location in the original candidate list (which is sorted by path). Force the sorting by similarity done with a stable sort, which is not promised by system supplied qsort(3), to ensure consistent results across platforms. * js/diff-rename-force-stable-sort: diffcore_rename(): use a stable sort Move git_sort(), a stable sort, into into libgit.a
2019-10-06msvc: work around a bug in GetEnvironmentVariable()Johannes Schindelin
The return value of that function is 0 both for variables that are unset, as well as for variables whose values are empty. To discern those two cases, one has to call `GetLastError()`, whose return value is `ERROR_ENVVAR_NOT_FOUND` and `ERROR_SUCCESS`, respectively. Except that it is not actually set to `ERROR_SUCCESS` in the latter case, apparently, but the last error value seems to be simply unchanged. To work around this, let's just re-set the last error value just before inspecting the environment variable. This fixes a problem that triggers failures in (where we try to override config settings by passing empty values for certain environment variables). This problem is hidden in the MINGW build by the fact that older MSVC runtimes (such as the one used by MINGW builds) have a `calloc()` that re-sets the last error value in case of success, while newer runtimes set the error value only if `NULL` is returned by that function. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-10-02Move git_sort(), a stable sort, into into libgit.aJohannes Schindelin
The `qsort()` function is not guaranteed to be stable, i.e. it does not promise to maintain the order of items it is told to consider equal. In contrast, the `git_sort()` function we carry in `compat/qsort.c` _is_ stable, by virtue of implementing a merge sort algorithm. In preparation for using a stable sort in Git's rename detection, move the stable sort into `libgit.a` so that it is compiled in unconditionally, and rename it to `git_stable_qsort()`. Note: this also makes the hack obsolete that was introduced in fe21c6b285d (mingw: reencode environment variables on the fly (UTF-16 <-> UTF-8), 2018-10-30), where we included `compat/qsort.c` directly in `compat/mingw.c` to use the stable sort. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-09-30Merge branch 'ar/mingw-run-external-with-non-ascii-path'Junio C Hamano
Windows update. * ar/mingw-run-external-with-non-ascii-path: mingw: fix launching of externals from Unicode paths
2019-09-05mingw: apply array.cocci ruleDenton Liu
After running Coccinelle on all sources inside compat/ that were created by us[1], it was found that compat/mingw.c violated an array.cocci rule in two places and, thus, a patch was generated. Apply this patch so that all compat/ sources created by us follows all cocci rules. [1]: Do not run Coccinelle on files that are taken from some upstream because in case we need to pull updates from them, we would like to have diverged as little as possible in order to make merging updates simpler. The following sources were determined to have been taken from some upstream: * compat/regex/ * compat/inet_ntop.c * compat/inet_pton.c * compat/nedmalloc/ * compat/obstack.{c,h} * compat/poll/ Signed-off-by: Denton Liu <> Acked-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-08-26mingw: fix launching of externals from Unicode pathsAdam Roben
If Git were installed in a path containing non-ASCII characters, commands such as `git am` and `git submodule`, which are implemented as externals, would fail to launch with the following error: > fatal: 'am' appears to be a git command, but we were not > able to execute it. Maybe git-am is broken? This was due to lookup_prog not being Unicode-aware. It was somehow missed in 85faec9d3a (Win32: Unicode file name support (except dirent), 2012-03-15). Note that the only problem in this function was calling `GetFileAttributes()` instead of `GetFileAttributesW()`. The calls to `access()` were fine because `access()` is a macro which resolves to `mingw_access()`, which already handles Unicode correctly. But `lookup_prog()` was changed to use `_waccess()` directly so that we only convert the path to UTF-16 once. To make things work correctly, we have to maintain UTF-8 and UTF-16 versions in tandem in `lookup_prog()`. Signed-off-by: Adam Roben <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-07-25Merge branch 'js/mingw-spawn-with-spaces-in-path'Junio C Hamano
Window 7 update ;-) * js/mingw-spawn-with-spaces-in-path: mingw: support spawning programs containing spaces in their names
2019-07-19Merge branch 'kb/mingw-set-home'Junio C Hamano
Windows port update. * kb/mingw-set-home: mingw: initialize HOME on startup
2019-07-16mingw: support spawning programs containing spaces in their namesJohannes Schindelin
On some older Windows versions (e.g. Windows 7), the CreateProcessW() function does not really support spaces in its first argument, lpApplicationName. But it supports passing NULL as lpApplicationName, which makes it figure out the application from the (possibly quoted) first argument of lpCommandLine. Let's use that trick (if we are certain that the first argument matches the executable's path) to support launching programs whose path contains spaces. We will abuse the test-fake-ssh.exe helper to verify that this works and does not regress. This fixes Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-07-11Merge branch 'js/mingw-use-utf8'Junio C Hamano
Windows update. * js/mingw-use-utf8: mingw: fix possible buffer overrun when calling `GetUserNameW()` mingw: use Unicode functions explicitly mingw: get pw_name in UTF-8 format
2019-07-08mingw: initialize HOME on startupKarsten Blees
HOME initialization was historically duplicated in many different places, including /etc/profile, launch scripts such as git-bash.vbs and gitk.cmd, and (although slightly broken) in the git-wrapper. Even unrelated projects such as GitExtensions and TortoiseGit need to implement the same logic to be able to call git directly. Initialize HOME in git's own startup code so that we can eventually retire all the duplicate initialization code. Signed-off-by: Karsten Blees <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-07-08mingw: fix possible buffer overrun when calling `GetUserNameW()`Johannes Schindelin
In 39a98e9b68b8 (mingw: get pw_name in UTF-8 format, 2019-06-27), this developer missed the fact that the `GetUserNameW()` function takes the number of characters as `len` parameter, not the number of bytes. Reported-by: Beat Bolli <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-06-27mingw: use Unicode functions explicitlyJohannes Schindelin
Many Win32 API functions actually exist in two variants: one with the `A` suffix that takes ANSI parameters (`char *` or `const char *`) and one with the `W` suffix that takes Unicode parameters (`wchar_t *` or `const wchar_t *`). The ANSI variant assumes that the strings are encoded according to whatever is the current locale. This is not what Git wants to use on Windows: we assume that `char *` variables point to strings encoded in UTF-8. There is a pseudo UTF-8 locale on Windows, but it does not work as one might expect. In addition, if we overrode the user's locale, that would modify the behavior of programs spawned by Git (such as editors, difftools, etc), therefore we cannot use that pseudo locale. Further, it is actually highly encouraged to use the Unicode versions instead of the ANSI versions, so let's do precisely that. Note: when calling the Win32 API functions _without_ any suffix, it depends whether the `UNICODE` constant is defined before the relevant headers are #include'd. Without that constant, the ANSI variants are used. Let's be explicit and avoid that ambiguity. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-06-27mingw: get pw_name in UTF-8 formatJohannes Schindelin
Previously, we would have obtained the user name encoded in whatever the current code page is. Note: the "user name" here does not denote the full name but instead the short logon name. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-06-25msvc: avoid debug assertion windows in Debug ModeJohannes Schindelin
For regular debugging, it is pretty helpful when a debug assertion in a running application triggers a window that offers to start the debugger. However, when running the test suite, it is not so helpful, in particular when the debug assertions are then suppressed anyway because we disable the invalid parameter checking (via invalidcontinue.obj, see the comment in config.mak.uname about that object for more information). So let's simply disable that window in Debug Mode (it is already disabled in Release Mode). Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-06-25msvc: do not pretend to support all signalsJeff Hostetler
This special-cases various signals that are not supported on Windows, such as SIGPIPE. These cause the UCRT to throw asserts (at least in debug mode). Signed-off-by: Jeff Hostetler <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-06-25msvc: add a compile-time flag to allow detailed heap debuggingJeff Hostetler
MS Visual C comes with a few neat features we can use to analyze the heap consumption (i.e. leaks, max memory, etc). With this patch, we introduce support via the build-time flag `USE_MSVC_CRTDBG`. Signed-off-by: Jeff Hostetler <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-06-25msvc: support building Git using MS Visual C++Jeff Hostetler
With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <> Helped-by: Philip Oakley <> Signed-off-by: Jeff Hostetler <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-06-20msvc: mark a variable as non-constJeff Hostetler
VS2015 complains when using a const pointer in memcpy()/free(). Signed-off-by: Jeff Hostetler <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-06-20mingw: replace mingw_startup() hackJohannes Schindelin
Git for Windows has special code to retrieve the command-line parameters (and even the environment) in UTF-16 encoding, so that they can be converted to UTF-8. This is necessary because Git for Windows wants to use UTF-8 encoded strings throughout its code, and the main() function does not get the parameters in that encoding. To do that, we used the __wgetmainargs() function, which is not even a Win32 API function, but provided by the MINGW "runtime" instead. Obviously, this method would not work with any compiler other than GCC, and in preparation for compiling with Visual C++, we would like to avoid precisely that. Lucky us, there is a much more elegant way: we can simply implement the UTF-16 variant of `main()`: `wmain()`. To make that work, we need to link with -municode. The command-line parameters are passed to `wmain()` encoded in UTF-16, as desired, and this method also works with GCC, and also with Visual C++ after adjusting the MSVC linker flags to force it to use `wmain()`. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-05-19Merge branch 'tt/no-ipv6-fallback-for-winxp'Junio C Hamano
Code cleanup. * tt/no-ipv6-fallback-for-winxp: mingw: remove obsolete IPv6-related code
2019-05-07mingw: remove obsolete IPv6-related codeTanushree Tumane
To support IPv6, Git provided fall back functions for Windows versions that did not support IPv6. However, as Git dropped support for Windows XP and prior, those functions are not needed anymore. Remove those fallbacks by reverting fe3b2b7b827c (Enable support for IPv6 on MinGW, 2009-11-24) and using the functions directly (without 'ipv6_' prefix). Signed-off-by: Tanushree Tumane <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-04-16trace2: refactor setting process starting timeJeff Hostetler
Create trace2_initialize_clock() and call from main() to capture process start time in isolation and before other sub-systems are ready. Signed-off-by: Jeff Hostetler <> Signed-off-by: Junio C Hamano <>
2019-02-22trace2: create new combined trace facilityJeff Hostetler
Create a new unified tracing facility for git. The eventual intent is to replace the current trace_printf* and trace_performance* routines with a unified set of git_trace2* routines. In addition to the usual printf-style API, trace2 provides higer-level event verbs with fixed-fields allowing structured data to be written. This makes post-processing and analysis easier for external tools. Trace2 defines 3 output targets. These are set using the environment variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT". These may be set to "1" or to an absolute pathname (just like the current GIT_TRACE). * GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command summary data. * GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE. It extends the output with columns for the command process, thread, repo, absolute and relative elapsed times. It reports events for child process start/stop, thread start/stop, and per-thread function nesting. * GIT_TR2_EVENT is a new structured format. It writes event data as a series of JSON records. Calls to trace2 functions log to any of the 3 output targets enabled without the need to call different trace_printf* or trace_performance* routines. Signed-off-by: Jeff Hostetler <> Signed-off-by: Junio C Hamano <>
2019-02-15mingw: safe-guard a bit more against getenv() problemsJohannes Schindelin
Running up to v2.21.0, we fixed two bugs that were made prominent by the Windows-specific change to retain copies of only the 30 latest getenv() calls' returned strings, invalidating any copies of previous getenv() calls' return values. While this really shines a light onto bugs of the form where we hold onto getenv()'s return values without copying them, it is also a real problem for users. And even if Jeff King's patches merged via 773e408881 (Merge branch 'jk/save-getenv-result', 2019-01-29) provide further work on that front, we are far from done. Just one example: on Windows, we unset environment variables when spawning new processes, which potentially invalidates strings that were previously obtained via getenv(), and therefore we have to duplicate environment values that are somehow involved in spawning new processes (e.g. GIT_MAN_VIEWER in show_man_page()). We do not have a chance to investigate, let address, all of those issues in time for v2.21.0, so let's at least help Windows users by increasing the number of getenv() calls' return values that are kept valid. The number 64 was determined by looking at the average number of getenv() calls per process in the entire test suite run on Windows (which is around 40) and then adding a bit for good measure. And it is a power of two (which would have hit yesterday's theme perfectly). Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-02-07Merge branch 'js/vsts-ci'Junio C Hamano
Prepare to run test suite on Azure Pipeline. * js/vsts-ci: (22 commits) test-date: drop unused parameter to getnanos() ci: parallelize testing on Windows ci: speed up Windows phase tests: optionally skip bin-wrappers/ t0061: workaround issues with --with-dashes and RUNTIME_PREFIX tests: add t/helper/ to the PATH with --with-dashes mingw: try to work around issues with the test cleanup tests: include detailed trace logs with --write-junit-xml upon failure tests: avoid calling Perl just to determine file sizes README: add a build badge (status of the Azure Pipelines build) mingw: be more generous when wrapping up the setitimer() emulation ci: use git-sdk-64-minimal build artifact ci: add a Windows job to the Azure Pipelines definition Add a build definition for Azure DevOps ci/ add support for Azure Pipelines tests: optionally write results as JUnit-style .xml test-date: add a subcommand to measure times in shell scripts ci: use a junction on Windows instead of a symlink ci: inherit --jobs via MAKEFLAGS in run-build-and-tests ci/ encapsulate Travis-specific things ...
2019-01-29mingw: be more generous when wrapping up the setitimer() emulationJohannes Schindelin
Every once in a while, the Azure Pipeline fails with some semi-random error: timer thread did not terminate timely This error message means that the thread that is used to emulate the setitimer() function did not terminate within 1,000 milliseconds. The most likely explanation (and therefore the one we should assume to be true, according to Occam's Razor) is that the timeout of one second is simply not enough because we try to run so many tasks in parallel. So let's give it ten seconds instead of only one. That should be enough. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-01-18mingw: special-case arguments to `sh`Johannes Schindelin
The MSYS2 runtime does its best to emulate the command-line wildcard expansion and de-quoting which would be performed by the calling Unix shell on Unix systems. Those Unix shell quoting rules differ from the quoting rules applying to Windows' cmd and Powershell, making it a little awkward to quote command-line parameters properly when spawning other processes. In particular, git.exe passes arguments to subprocesses that are *not* intended to be interpreted as wildcards, and if they contain backslashes, those are not to be interpreted as escape characters, e.g. when passing Windows paths. Note: this is only a problem when calling MSYS2 executables, not when calling MINGW executables such as git.exe. However, we do call MSYS2 executables frequently, most notably when setting the use_shell flag in the child_process structure. There is no elegant way to determine whether the .exe file to be executed is an MSYS2 program or a MINGW one. But since the use case of passing a command line through the shell is so prevalent, we need to work around this issue at least when executing sh.exe. Let's introduce an ugly, hard-coded test whether argv[0] is "sh", and whether it refers to the MSYS2 Bash, to determine whether we need to quote the arguments differently than usual. That still does not fix the issue completely, but at least it is something. Incidentally, this also fixes the problem where `git clone \\server\repo` failed due to incorrect handling of the backslashes when handing the path to the git-upload-pack process. Further, we need to take care to quote not only whitespace and backslashes, but also curly brackets. As aliases frequently go through the MSYS2 Bash, and as aliases frequently get parameters such as HEAD@{yesterday}, this is really important. As an early version of this patch broke this, let's make sure that this does not regress by adding a test case for that. Helped-by: Kim Gybels <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-01-14Merge branch 'tb/use-common-win32-pathfuncs-on-cygwin'Junio C Hamano
Cygwin update. * tb/use-common-win32-pathfuncs-on-cygwin: git clone <url> C:\cygwin\home\USER\repo' is working (again)
2018-12-26git clone <url> C:\cygwin\home\USER\repo' is working (again)Torsten Bögershausen
A regression for cygwin users was introduced with commit 05b458c, "real_path: resolve symlinks by hand". In the the commit message we read: The current implementation of real_path uses chdir() in order to resolve symlinks. Unfortunately this isn't thread-safe as chdir() affects a process as a whole... The old (and non-thread-save) OS calls chdir()/pwd() had been replaced by a string operation. The cygwin layer "knows" that "C:\cygwin" is an absolute path, but the new string operation does not. "git clone <url> C:\cygwin\home\USER\repo" fails like this: fatal: Invalid path '/home/USER/repo/C:\cygwin\home\USER\repo' The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix() is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin in the same way as it is done in 'Git for Windows' in compat/mingw.[ch] Extract the needed code into compat/win32/path-utils.[ch] and use it for cygwin as well. Reported-by: Steven Penny <> Helped-by: Johannes Schindelin <> Signed-off-by: Torsten Bögershausen <> Signed-off-by: Junio C Hamano <>
2018-11-18Merge branch 'js/mingw-msdn-url'Junio C Hamano
The URL to an MSDN page in a comment has been updated. * js/mingw-msdn-url: mingw: replace an obsolete link with the superseding one
2018-11-16mingw: replace an obsolete link with the superseding oneJohannes Schindelin
The MSDN documentation has been superseded by Microsoft Docs (which is backed by a repository on GitHub containing many, many files in Markdown format). Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-11-14mingw: use `CreateHardLink()` directlyJohannes Schindelin
The function `CreateHardLink()` is available in all supported Windows versions (even since Windows XP), so there is no more need to resolve it at runtime. Helped-by: Max Kirillov <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-11-13Merge branch 'js/mingw-utf8-env'Junio C Hamano
Windows fix. * js/mingw-utf8-env: mingw: reencode environment variables on the fly (UTF-16 <-> UTF-8) t7800: fix quoting
2018-11-13Merge branch 'js/mingw-perl5lib'Junio C Hamano
Windows fix. * js/mingw-perl5lib: mingw: unset PERL5LIB by default config: move Windows-specific config settings into compat/mingw.c config: allow for platform-specific core.* config settings config: rename `dummy` parameter to `cb` in git_default_config()
2018-11-06Merge branch 'js/mingw-ns-filetime'Junio C Hamano
Windows port learned to use nano-second resolution file timestamps. * js/mingw-ns-filetime: mingw: implement nanosecond-precision file times mingw: replace MSVCRT's fstat() with a Win32-based implementation mingw: factor out code to set stat() data
2018-10-31mingw: unset PERL5LIB by defaultJohannes Schindelin
Git for Windows ships with its own Perl interpreter, and insists on using it, so it will most likely wreak havoc if PERL5LIB is set before launching Git. Let's just unset that environment variables when spawning processes. To make this feature extensible (and overrideable), there is a new config setting `core.unsetenvvars` that allows specifying a comma-separated list of names to unset before spawning processes. Reported by Gabriel Fuhrmann. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-10-31config: move Windows-specific config settings into compat/mingw.cJohannes Schindelin
Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-10-31config: allow for platform-specific core.* config settingsJohannes Schindelin
In the Git for Windows project, we have ample precendent for config settings that apply to Windows, and to Windows only. Let's formalize this concept by introducing a platform_core_config() function that can be #define'd in a platform-specific manner. This will allow us to contain platform-specific code better, as the corresponding variables no longer need to be exported so that they can be defined in environment.c and be set in config.c Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-10-31mingw: reencode environment variables on the fly (UTF-16 <-> UTF-8)Johannes Schindelin
On Windows, the authoritative environment is encoded in UTF-16. In Git for Windows, we convert that to UTF-8 (because UTF-16 is *such* a foreign idea to Git that its source code is unprepared for it). Previously, out of performance concerns, we converted the entire environment to UTF-8 in one fell swoop at the beginning, and upon putenv() and run_command() converted it back. Having a private copy of the environment comes with its own perils: when a library used by Git's source code tries to modify the environment, it does not really work (in Git for Windows' case, libcurl, see^...bcad1e6d58^2 for a glimpse of the issues). Hence, it makes our environment handling substantially more robust if we switch to on-the-fly-conversion in `getenv()`/`putenv()` calls. Based on an initial version in the MSVC context by Jeff Hostetler, this patch makes it so. Surprisingly, this has a *positive* effect on speed: at the time when the current code was written, we tested the performance, and there were *so many* `getenv()` calls that it seemed better to convert everything in one go. In the meantime, though, Git has obviously been cleaned up a bit with regards to `getenv()` calls so that the Git processes spawned by the test suite use an average of only 40 `getenv()`/`putenv()` calls over the process lifetime. Speaking of the entire test suite: the total time spent in the re-encoding in the current code takes about 32.4 seconds (out of 113 minutes runtime), whereas the code introduced in this patch takes only about 8.2 seconds in total. Not much, but it proves that we need not be concerned about the performance impact introduced by this patch. Helped-by: Jeff Hostetler <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-10-30Merge branch 'js/mingw-load-sys-dll'Junio C Hamano
The way DLLs are loaded on the Windows port has been improved. * js/mingw-load-sys-dll: mingw: load system libraries the recommended way
2018-10-30Merge branch 'js/mingw-getcwd'Junio C Hamano
The way the Windows port figures out the current directory has been improved. * js/mingw-getcwd: mingw: fix getcwd when the parent directory cannot be queried mingw: ensure `getcwd()` reports the correct case
2018-10-26Merge branch 'js/mingw-default-ident'Junio C Hamano
The logic to select the default user name and e-mail on Windows has been improved. * js/mingw-default-ident: mingw: use domain information for default email getpwuid(mingw): provide a better default for the user name getpwuid(mingw): initialize the structure only once
2018-10-24mingw: fix getcwd when the parent directory cannot be queriedAnton Serbulov
`GetLongPathName()` function may fail when it is unable to query the parent directory of a path component to determine the long name for that component. It happens, because it uses `FindFirstFile()` function for each next short part of path. The `FindFirstFile()` requires `List Directory` and `Synchronize` desired access for a calling process. In case of lacking such permission for some part of path, the `GetLongPathName()` returns 0 as result and `GetLastError()` returns ERROR_ACCESS_DENIED. `GetFinalPathNameByHandle()` function can help in such cases, because it requires `Read Attributes` and `Synchronize` desired access to the target path only. The `GetFinalPathNameByHandle()` function was introduced on `Windows Server 2008/Windows Vista`. So we need to load it dynamically. `CreateFile()` parameters: `lpFileName` = path to the current directory `dwDesiredAccess` = 0 (it means `Read Attributes` and `Synchronize`) `dwShareMode` = FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE (it prevents `Sharing Violation`) `lpSecurityAttributes` = NULL (default security attributes) `dwCreationDisposition` = OPEN_EXISTING (required to obtain a directory handle) `dwFlagsAndAttributes` = FILE_FLAG_BACKUP_SEMANTICS (required to obtain a directory handle) `hTemplateFile` = NULL (when opening an existing file or directory, `CreateFile` ignores this parameter) The string that is returned by `GetFinalPathNameByHandle()` function uses the \\?\ syntax. To skip the prefix and convert backslashes to slashes, the `normalize_ntpath()` mingw function will be used. Note: `GetFinalPathNameByHandle()` function returns a final path. It is the path that is returned when a path is fully resolved. For example, for a symbolic link named "C:\tmp\mydir" that points to "D:\yourdir", the final path would be "D:\yourdir". Signed-off-by: Anton Serbulov <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-10-24mingw: ensure `getcwd()` reports the correct caseJohannes Schindelin
When switching the current working directory, say, in PowerShell, it is quite possible to use a different capitalization than the one that is recorded on disk. While doing the same in `cmd.exe` adjusts the capitalization magically, that does not happen in PowerShell so that `getcwd()` returns the current directory in a different way than is recorded on disk. Typically this creates no problems except when you call git log . in a subdirectory called, say, "GIT/" but you switched to "Git/" and your `getcwd()` reports the latter, then Git won't understand that you wanted to see the history as per the `GIT/` subdirectory but it thinks you wanted to see the history of some directory that may have existed in the past (but actually never did). So let's be extra careful to adjust the capitalization of the current directory before working with it. Reported by a few PowerShell power users ;-) Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-10-24mingw: load system libraries the recommended wayJohannes Schindelin
When we access IPv6-related functions, we load the corresponding system library using the `LoadLibrary()` function, which is not the recommended way to load system libraries. In practice, it does not make a difference: the `ws2_32.dll` library containing the IPv6 functions is already loaded into memory, so LoadLibrary() simply reuses the already-loaded library. Still, recommended way is recommended way, so let's use that instead. While at it, also adjust the code in contrib/ that loads system libraries. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-10-24mingw: implement nanosecond-precision file timesKarsten Blees
We no longer use any of MSVCRT's stat-functions, so there's no need to stick to a CRT-compatible 'struct stat' either. Define and use our own POSIX-2013-compatible 'struct stat' with nanosecond- precision file times. Note: This can cause performance issues when using Git variants with different file time resolutions, as the timestamps are stored in the Git index: after updating the index with a Git variant that uses second-precision file times, a nanosecond-aware Git will think that pretty much every single file listed in the index is out of date. Signed-off-by: Karsten Blees <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>