summaryrefslogtreecommitdiff
path: root/compat
AgeCommit message (Collapse)AuthorFilesLines
2019-03-11Merge branch 'jk/guard-bswap-header'Libravatar Junio C Hamano1-0/+5
The include file compat/bswap.h has been updated so that it is safe to (accidentally) include it more than once. * jk/guard-bswap-header: compat/bswap: add include header guards
2019-03-07compat/bswap: add include header guardsLibravatar Jeff King1-0/+5
Our compat/bswap.h lacks the usual preprocessor guards against multiple inclusion. This usually isn't an issue since it only gets included from git-compat-util.h, which has its own guards. But it would produce redeclaration errors if any file included it separately. Our hdr-check target would complain about this, except that it currently skips items in compat/ entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22trace2: collect Windows-specific process informationLibravatar Jeff Hostetler1-0/+147
Add platform-specific interface to log information about the current process. On Windows, this interface is used to indicate whether the git process is running under a debugger and list names of the process ancestors. Information for other platforms is left for a future effort. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22trace2: create new combined trace facilityLibravatar Jeff Hostetler2-3/+11
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 <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-15mingw: safe-guard a bit more against getenv() problemsLibravatar Johannes Schindelin1-1/+1
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 <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13Merge branch 'js/mingw-host-cpu'Libravatar Junio C Hamano1-19/+0
Windows update. * js/mingw-host-cpu: mingw: use a more canonical method to fix the CPU reporting
2019-02-13Merge branch 'nd/fileno-may-be-macro'Libravatar Junio C Hamano1-0/+7
* nd/fileno-may-be-macro: git-compat-util: work around fileno(fp) that is a macro
2019-02-13mingw: use a more canonical method to fix the CPU reportingLibravatar Johannes Schindelin1-19/+0
In `git version --build-options`, we report also the CPU, but in Git for Windows we actually cross-compile the 32-bit version in a 64-bit Git for Windows, so we cannot rely on the auto-detected value. In 3815f64b0dd9 (mingw: fix CPU reporting in `git version --build-options`, 2019-02-07), we fixed this by a Windows-only workaround, making use of magic pre-processor constants, which works in GCC, but most likely not all C compilers. As pointed out by Eric Sunshine, there is a better way, anyway: to set the Makefile variable HOST_CPU explicitly for cross-compiled Git. So let's do that! This reverts commit 3815f64b0dd983bdbf9242a0547706d5d81cb3e6 partially. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-12git-compat-util: work around fileno(fp) that is a macroLibravatar Duy Nguyen1-0/+7
On various BSD's, fileno(fp) is implemented as a macro that directly accesses the fields in the FILE * object, which breaks a function that accepts a "void *fp" parameter and calls fileno(fp) and expect it to work. Work it around by adding a compile-time knob FILENO_IS_A_MACRO that inserts a real helper function in the middle of the callchain. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-08Merge branch 'js/mingw-host-cpu'Libravatar Junio C Hamano1-0/+19
Windows update. * js/mingw-host-cpu: mingw: fix CPU reporting in `git version --build-options`
2019-02-07mingw: fix CPU reporting in `git version --build-options`Libravatar Johannes Schindelin1-0/+19
We cannot rely on `uname -m` in Git for Windows' SDK to tell us what architecture we are compiling for, as we can compile both 32-bit and 64-bit `git.exe` from a 64-bit SDK, but the `uname -m` in that SDK will always report `x86_64`. So let's go back to our original design. And make it explicitly Windows-specific. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-06Merge branch 'js/vsts-ci'Libravatar Junio C Hamano1-1/+1
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/lib.sh: 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/lib.sh: encapsulate Travis-specific things ...
2019-02-06Merge branch 'tb/utf-16-le-with-explicit-bom'Libravatar Junio C Hamano1-1/+1
A new encoding UTF-16LE-BOM has been invented to force encoding to UTF-16 with BOM in little endian byte order, which cannot be directly generated by using iconv. * tb/utf-16-le-with-explicit-bom: Support working-tree-encoding "UTF-16LE-BOM"
2019-02-05Merge branch 'js/mingw-unc-path-w-backslashes'Libravatar Junio C Hamano1-1/+76
In Git for Windows, "git clone \\server\share\path" etc. that uses UNC paths from command line had bad interaction with its shell emulation. * js/mingw-unc-path-w-backslashes: mingw: special-case arguments to `sh` mingw (t5580): document bug when cloning from backslashed UNC paths
2019-02-05Merge branch 'sg/obstack-cast-function-type-fix'Libravatar Junio C Hamano2-15/+20
The compat/obstack code had casts that -Wcast-function-type compilation option found questionable. * sg/obstack-cast-function-type-fix: compat/obstack: fix -Wcast-function-type warnings
2019-01-31Support working-tree-encoding "UTF-16LE-BOM"Libravatar Torsten Bögershausen1-1/+1
Users who want UTF-16 files in the working tree set the .gitattributes like this: test.txt working-tree-encoding=UTF-16 The unicode standard itself defines 3 allowed ways how to encode UTF-16. The following 3 versions convert all back to 'g' 'i' 't' in UTF-8: a) UTF-16, without BOM, big endian: $ printf "\000g\000i\000t" | iconv -f UTF-16 -t UTF-8 | od -c 0000000 g i t b) UTF-16, with BOM, little endian: $ printf "\377\376g\000i\000t\000" | iconv -f UTF-16 -t UTF-8 | od -c 0000000 g i t c) UTF-16, with BOM, big endian: $ printf "\376\377\000g\000i\000t" | iconv -f UTF-16 -t UTF-8 | od -c 0000000 g i t Git uses libiconv to convert from UTF-8 in the index into ITF-16 in the working tree. After a checkout, the resulting file has a BOM and is encoded in "UTF-16", in the version (c) above. This is what iconv generates, more details follow below. iconv (and libiconv) can generate UTF-16, UTF-16LE or UTF-16BE: d) UTF-16 $ printf 'git' | iconv -f UTF-8 -t UTF-16 | od -c 0000000 376 377 \0 g \0 i \0 t e) UTF-16LE $ printf 'git' | iconv -f UTF-8 -t UTF-16LE | od -c 0000000 g \0 i \0 t \0 f) UTF-16BE $ printf 'git' | iconv -f UTF-8 -t UTF-16BE | od -c 0000000 \0 g \0 i \0 t There is no way to generate version (b) from above in a Git working tree, but that is what some applications need. (All fully unicode aware applications should be able to read all 3 variants, but in practise we are not there yet). When producing UTF-16 as an output, iconv generates the big endian version with a BOM. (big endian is probably chosen for historical reasons). iconv can produce UTF-16 files with little endianess by using "UTF-16LE" as encoding, and that file does not have a BOM. Not all users (especially under Windows) are happy with this. Some tools are not fully unicode aware and can only handle version (b). Today there is no way to produce version (b) with iconv (or libiconv). Looking into the history of iconv, it seems as if version (c) will be used in all future iconv versions (for compatibility reasons). Solve this dilemma and introduce a Git-specific "UTF-16LE-BOM". libiconv can not handle the encoding, so Git pick it up, handles the BOM and uses libiconv to convert the rest of the stream. (UTF-16BE-BOM is added for consistency) Rported-by: Adrián Gimeno Balaguer <adrigibal@gmail.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-29mingw: be more generous when wrapping up the setitimer() emulationLibravatar Johannes Schindelin1-1/+1
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 <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-18Merge branch 'rb/hpe'Libravatar Junio C Hamano1-0/+8
Portability updates for the HPE NonStop platform. * rb/hpe: compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStop git-compat-util.h: add FLOSS headers for HPE NonStop config.mak.uname: support for modern HPE NonStop config. transport-helper: drop read/write errno checks transport-helper: use xread instead of read
2019-01-18mingw: special-case arguments to `sh`Libravatar Johannes Schindelin1-1/+76
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 <kgybels@infogroep.be> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-17compat/obstack: fix -Wcast-function-type warningsLibravatar SZEDER Gábor2-15/+20
GCC 8 introduced the new -Wcast-function-type warning, which is implied by -Wextra (which, in turn is enabled in our DEVELOPER flags). When building Git with GCC 8 and this warning enabled on a non-glibc platform [1], one is greeted with a screenful of compiler warnings/errors: compat/obstack.c: In function '_obstack_begin': compat/obstack.c:162:17: error: cast between incompatible function types from 'void * (*)(long int)' to 'struct _obstack_chunk * (*)(void *, long int)' [-Werror=cast-function-type] h->chunkfun = (struct _obstack_chunk * (*)(void *, long)) chunkfun; ^ compat/obstack.c:163:16: error: cast between incompatible function types from 'void (*)(void *)' to 'void (*)(void *, struct _obstack_chunk *)' [-Werror=cast-function-type] h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun; ^ compat/obstack.c:116:8: error: cast between incompatible function types from 'struct _obstack_chunk * (*)(void *, long int)' to 'struct _obstack_chunk * (*)(long int)' [-Werror=cast-function-type] : (*(struct _obstack_chunk *(*) (long)) (h)->chunkfun) ((size))) ^ compat/obstack.c:168:22: note: in expansion of macro 'CALL_CHUNKFUN' chunk = h->chunk = CALL_CHUNKFUN (h, h -> chunk_size); ^~~~~~~~~~~~~ <snip> 'struct obstack' stores pointers to two functions to allocate and free "chunks", and depending on how obstack is used, these functions take either one parameter (like standard malloc() and free() do; this is how we use it in 'kwset.c') or two parameters. Presumably to reduce memory footprint, a single field is used to store the function pointer for both signatures, and then it's casted to the appropriate signature when the function pointer is accessed. These casts between function pointers with different number of parameters are what trigger those compiler errors. Modify 'struct obstack' to use unions to store function pointers with different signatures, and then use the union member with the appropriate signature when accessing these function pointers. This eliminates the need for those casts, and thus avoids this compiler error. [1] Compiling 'compat/obstack.c' on a platform with glibc is sort of a noop, see the comment before '# define ELIDE_CODE', so this is not an issue on common Linux distros. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-14Merge branch 'tb/use-common-win32-pathfuncs-on-cygwin'Libravatar Junio C Hamano6-69/+49
Cygwin update. * tb/use-common-win32-pathfuncs-on-cygwin: git clone <url> C:\cygwin\home\USER\repo' is working (again)
2019-01-03compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStopLibravatar Randall S. Becker1-0/+8
The system definition header files on HPE NonStop do not define intptr_t and uintptr_t as do other platforms. These typedefs are added specifically wrapped in a __TANDEM ifdef. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-26git clone <url> C:\cygwin\home\USER\repo' is working (again)Libravatar Torsten Bögershausen6-69/+49
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 <svnpenn@gmail.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-01Merge branch 'ss/msvc-strcasecmp'Libravatar Junio C Hamano1-7/+1
MSVC update. * ss/msvc-strcasecmp: msvc: directly use MS version (_stricmp) of strcasecmp
2018-11-21Merge branch 'js/mingw-o-append' into maintLibravatar Junio C Hamano1-3/+33
Further fix for O_APPEND emulation on Windows * js/mingw-o-append: mingw: fix mingw_open_append to work with named pipes t0051: test GIT_TRACE to a windows named pipe
2018-11-20msvc: directly use MS version (_stricmp) of strcasecmpLibravatar Sven Strickroth1-7/+1
This also removes an implicit conversion from size_t (unsigned) to int (signed). _stricmp as well as _strnicmp are both available since VS2012. Signed-off-by: Sven Strickroth <email@cs-ware.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-18Merge branch 'js/mingw-msdn-url'Libravatar Junio C Hamano1-2/+2
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-18Merge branch 'js/mingw-create-hard-link'Libravatar Junio C Hamano1-13/+1
Windows update. * js/mingw-create-hard-link: mingw: use `CreateHardLink()` directly
2018-11-16mingw: replace an obsolete link with the superseding oneLibravatar Johannes Schindelin1-2/+2
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 <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14win32: replace pthread_cond_*() with much simpler codeLibravatar Loo Rong Jie2-159/+7
The Win32 CONDITION_VARIABLE has better performance and is easier to maintain, as the code is a lot shorter now (the semantics of the CONDITION_VARIABLE matches the pthread_cond_t very well). Note: CONDITION_VARIABLE is not available in Windows XP and below, but the declared minimal Windows version required to build and run Git for Windows is Windows Vista (which is also beyond its end-of-life, but for less long than Windows XP), so that's okay. Signed-off-by: Loo Rong Jie <loorongjie@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14mingw: use `CreateHardLink()` directlyLibravatar Johannes Schindelin1-13/+1
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 <max@max630.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13Merge branch 'sh/mingw-safer-compat-poll'Libravatar Junio C Hamano1-4/+8
Windows fix. * sh/mingw-safer-compat-poll: poll: use GetTickCount64() to avoid wrap-around issues
2018-11-13Merge branch 'js/mingw-utf8-env'Libravatar Junio C Hamano2-116/+196
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'Libravatar Junio C Hamano2-1/+60
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-13Merge branch 'js/mingw-isatty-and-dup2'Libravatar Junio C Hamano2-0/+15
Windows fix. * js/mingw-isatty-and-dup2: mingw: fix isatty() after dup2()
2018-11-06Merge branch 'js/mingw-ns-filetime'Libravatar Junio C Hamano2-36/+76
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-11-05poll: use GetTickCount64() to avoid wrap-around issuesLibravatar Steve Hoelzer1-4/+8
The value of timeout starts as an int value, and for this reason it cannot overflow unsigned long long aka ULONGLONG. The unsigned version of this initial value is available in orig_timeout. The difference (orig_timeout - elapsed) cannot wrap around because it is protected by a conditional (as can be seen in the patch text). Hence, the ULONGLONG difference can only have values that are smaller than the initial timeout value and truncation to int cannot overflow. Signed-off-by: Steve Hoelzer <shoelzer@gmail.com> [j6t: improved both implementation and log message] Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31mingw: fix isatty() after dup2()Libravatar Johannes Schindelin2-0/+15
Since a9b8a09c3c30 (mingw: replace isatty() hack, 2016-12-22), we handle isatty() by special-casing the stdin/stdout/stderr file descriptors, caching the return value. However, we missed the case where dup2() overrides the respective file descriptor. That poses a problem e.g. where the `show` builtin asks for a pager very early, the `setup_pager()` function sets the pager depending on the return value of `isatty()` and then redirects stdout. Subsequently, `cmd_log_init_finish()` calls `setup_pager()` *again*. What should happen now is that `isatty()` reports that stdout is *not* a TTY and consequently stdout should be left alone. Let's override dup2() to handle this appropriately. This fixes https://github.com/git-for-windows/git/issues/1077 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31mingw: unset PERL5LIB by defaultLibravatar Johannes Schindelin1-1/+34
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 <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31config: move Windows-specific config settings into compat/mingw.cLibravatar Johannes Schindelin1-0/+18
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31config: allow for platform-specific core.* config settingsLibravatar Johannes Schindelin2-0/+8
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 <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31mingw: reencode environment variables on the fly (UTF-16 <-> UTF-8)Libravatar Johannes Schindelin2-116/+196
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 https://github.com/git-for-windows/git/compare/bcad1e6d58^...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 <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-30Merge branch 'cb/compat-mmap-is-private-read-only'Libravatar Junio C Hamano1-1/+1
Code tightening. * cb/compat-mmap-is-private-read-only: compat: make sure git_mmap is not expected to write
2018-10-30Merge branch 'js/mingw-load-sys-dll'Libravatar Junio C Hamano1-1/+2
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'Libravatar Junio C Hamano1-2/+48
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'Libravatar Junio C Hamano2-7/+55
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-25compat: make sure git_mmap is not expected to writeLibravatar Carlo Marcelo Arenas Belón1-1/+1
in f48000fc ("Yank writing-back support from gitfakemmap.", 2005-10-08) support for writting back changes was removed but the specific prot flag that would be used was not checked for Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-24mingw: fix getcwd when the parent directory cannot be queriedLibravatar Anton Serbulov1-0/+39
`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 <aserbulov@plesk.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-24mingw: ensure `getcwd()` reports the correct caseLibravatar Johannes Schindelin1-2/+9
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 <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-24mingw: load system libraries the recommended wayLibravatar Johannes Schindelin1-1/+2
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 <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>