summaryrefslogtreecommitdiff
path: root/config.mak.uname
AgeCommit message (Collapse)AuthorFilesLines
2019-07-29vcxproj: also link-or-copy builtinsLibravatar Johannes Schindelin1-0/+15
The default location for `.exe` files linked by Visual Studio depends on the mode (debug vs release) and the architecture. Meaning: after a full build, there is a `git.exe` in the top-level directory, but none of the built-ins are linked.. When running a test script in Git Bash, it therefore would pick up the wrong, say, `git-receive-pack.exe`: the one installed at the same time as the Git Bash. Absolutely not what we want. We want to have confidence that our test covers the MSVC-built Git executables, and not some random stuff. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29msvc: add a Makefile target to pre-generate the Visual Studio solutionLibravatar Johannes Schindelin1-0/+61
The entire idea of generating the VS solution makes only sense if we generate it via Continuous Integration; otherwise potential users would still have to download the entire Git for Windows SDK. If we pre-generate the Visual Studio solution, Git can be built entirely within Visual Studio, and the test scripts can be run in a regular Git for Windows (e.g. the Portable Git flavor, which does not include a full GCC toolchain and therefore weighs only about a tenth of Git for Windows' SDK). So let's just add a target in the Makefile that can be used to generate said solution; The generated files will then be committed so that they can be pushed to a branch ready to check out by Visual Studio users. To make things even more useful, we also generate and commit other files that are required to run the test suite, such as templates and bin-wrappers: with this, developers can run the test suite in a regular Git Bash after building the solution in Visual Studio. Note: for this build target, we do not actually need to initialize the `vcpkg` system, so we don't. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-11Merge branch 'js/mingw-gcc-stack-protect'Libravatar Junio C Hamano1-1/+2
Windows update. * js/mingw-gcc-stack-protect: mingw: enable stack smashing protector
2019-06-27mingw: enable stack smashing protectorLibravatar Johannes Schindelin1-1/+2
To reduce Git for Windows' attack surface, we started using the Address Space Layout Randomization and Data Execution Prevention features in ce6a158561f9 (mingw: enable DEP and ASLR, 2019-05-08). To remove yet another attack vector, let's make use of gcc's stack smashing protector that helps detect stack buffer overruns early. Rather than using -fstack-protector, we use -fstack-protector-strong because on Windows: The latter appears to strike a better balance between the performance impact and the provided safety. In a non-scientific test (time git log --grep=is -p), best of 5 timings went from 23.009s to 22.997s, i.e. the performance impact was *well* lost in the noise. This fixes https://github.com/git-for-windows/git/issues/501 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25msvc: add a compile-time flag to allow detailed heap debuggingLibravatar Jeff Hostetler1-0/+4
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 <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25msvc: support building Git using MS Visual C++Libravatar Jeff Hostetler1-10/+62
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 https://github.com/Microsoft/vcpkg 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 <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20msvc: fix dependencies of compat/msvc.cLibravatar Johannes Schindelin1-0/+2
The file compat/msvc.c includes compat/mingw.c, which means that we have to recompile compat/msvc.o if compat/mingw.c changes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20mingw: replace mingw_startup() hackLibravatar Johannes Schindelin1-1/+2
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 <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20mingw: fix a typo in the msysGit-specific sectionLibravatar Johannes Schindelin1-1/+1
The msysGit project (i.e. Git for Windows 1.x' SDK) is safely dead for *years* already. This is probably the reason why nobody caught this typo until Carlo Arenas spotted a copy-edited version of it nearby. It is probably about time to rip out the remainders of msysGit/MSys1 support, but that can safely wait a bit longer, and we can at least fix the typo for now. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-19Merge branch 'id/windows-dep-aslr'Libravatar Junio C Hamano1-0/+8
Allow DEP and ASLR for Windows build to for security hardening. * id/windows-dep-aslr: mingw: enable DEP and ASLR mingw: do not let ld strip relocations
2019-05-13Merge branch 'cc/access-on-aix-workaround'Libravatar Junio C Hamano1-0/+1
Workaround for standard-compliant but less-than-useful behaviour of access(2) for the root user. * cc/access-on-aix-workaround: git-compat-util: work around for access(X_OK) under root
2019-05-13mingw: enable DEP and ASLRLibravatar İsmail Dönmez1-0/+6
Enable DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization) support. This applies to both 32bit and 64bit builds and makes it substantially harder to exploit security holes in Git by offering a much more unpredictable attack surface. ASLR interferes with GDB's ability to set breakpoints. A similar issue holds true when compiling with -O2 (in which case single-stepping is messed up because GDB cannot map the code back to the original source code properly). Therefore we simply enable ASLR only when an optimization flag is present in the CFLAGS, using it as an indicator that the developer does not want to debug in GDB anyway. Signed-off-by: İsmail Dönmez <ismail@i10z.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13mingw: do not let ld strip relocationsLibravatar İsmail Dönmez1-0/+2
This is the first step for enabling ASLR (Address Space Layout Randomization) support. We want to enable ASLR for better protection against exploiting security holes in Git: it makes it harder to attack software by making code addresses unpredictable. The problem fixed by this commit is that `ld.exe` seems to be stripping relocations which in turn will break ASLR support. We just make sure it's not stripping the main executable entry. Signed-off-by: İsmail Dönmez <ismail@i10z.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-09Merge branch 'cc/aix-has-fileno-as-a-macro'Libravatar Junio C Hamano1-0/+1
AIX shared the same build issues with other BSDs around fileno(fp), which has been corrected. * cc/aix-has-fileno-as-a-macro: Makefile: use fileno macro work around on AIX
2019-05-09Merge branch 'ss/msvc-path-utils-fix'Libravatar Junio C Hamano1-0/+1
An earlier update for MinGW and Cygwin accidentally broke MSVC build, which has been fixed. * ss/msvc-path-utils-fix: MSVC: include compat/win32/path-utils.h for MSVC, too, for real_path()
2019-04-25git-compat-util: work around for access(X_OK) under rootLibravatar Clément Chigot1-0/+1
On AIX, access(X_OK) may succeed when run as root even if the execution isn't possible. This behavior is allowed by POSIX which says: ... for a process with appropriate privileges, an implementation may indicate success for X_OK even if execute permission is not granted to any user. It can lead hook programs to have their execution refused: git commit -m content fatal: cannot exec '.git/hooks/pre-commit': Permission denied Add NEED_ACCESS_ROOT_HANDLER in order to use an access helper function. It checks with stat if any executable flags is set when the current user is root. Signed-off-by: Clément Chigot <clement.chigot@atos.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-25Makefile: use fileno macro work around on AIXLibravatar Clément Chigot1-0/+1
Declare FILENO_IS_A_MACRO on AIX On AIX, fileno(fp) is a macro and need to use the work around already made for BSD's. Signed-off-by: Clément Chigot <clement.chigot@atos.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-25Merge branch 'js/macos-gettext-build'Libravatar Junio C Hamano1-0/+2
Build with gettext breaks on recent macOS w/ Homebrew when /usr/local/bin is not on PATH, which has been corrected. * js/macos-gettext-build: macOS: make sure that gettext is found
2019-04-15macOS: make sure that gettext is foundLibravatar Johannes Schindelin1-0/+2
Due to reasons (some XCode versions seem to include gettext, some don't?), Homebrew does not expose the libraries and headers in /usr/local/ by default anymore. Let's help find them again. Note: for some reason, this is a change of behavior caused by the upgrade to Mojave, identified in our Azure Pipeline; it seems that Homebrew used to add the /usr/local/ directories to the include and link search path before, but now it no longer does. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-09MSVC: include compat/win32/path-utils.h for MSVC, too, for real_path()Libravatar Sven Strickroth1-0/+1
A path such as 'c:/somepath/submodule/../.git/modules/submodule' wasn't resolved correctly any more, because the *nix variant of offset_1st_component is used instead of the Win32 specific version. Regression was introduced in commit 1cadad6f6 when mingw_offset_1st_component was moved from mingw.c which is included by msvc.c to a separate file. Then, the new file "compat/win32/path-utils.h" was only included for the __CYGWIN__ and __MINGW32__ cases in git-compat-util.h, the case for _MSC_VER was missing. Signed-off-by: Sven Strickroth <email@cs-ware.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-11Sync with maintLibravatar Junio C Hamano1-1/+1
* maint: mingw: allow building with an MSYS2 runtime v3.x
2019-03-11mingw: allow building with an MSYS2 runtime v3.xLibravatar Johannes Schindelin1-1/+1
Recently the Git for Windows project started the upgrade process to a MSYS2 runtime version based on Cygwin v3.x. This has the very notable consequence that `$(uname -r)` no longer reports a version starting with "2", but a version with "3". That breaks our build, as df5218b4c30b (config.mak.uname: support MSys2, 2016-01-13) simply did not expect the version reported by `uname -r` to depend on the underlying Cygwin version: it expected the reported version to match the "2" in "MSYS2". So let's invert that test case to test for *anything else* than a version starting with "1" (for MSys). That should safeguard us for the future, even if Cygwin ends up releasing versionsl like 314.272.65536. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-08mingw: drop MakeMaker referenceLibravatar Johannes Schindelin1-1/+0
In 20d2a30f8ffe (Makefile: replace perl/Makefile.PL with simple make rules, 2017-12-10), Git stopped using MakeMaker. Therefore, that definition in the MINGW-specific section became useless. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22trace2: collect Windows-specific process informationLibravatar Jeff Hostetler1-0/+2
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-13Merge branch 'rs/bash-is-in-coreutils-on-nonstop'Libravatar Junio C Hamano1-3/+1
* rs/bash-is-in-coreutils-on-nonstop: config.mak.uname: move location of bash on NonStop to CoreUtils
2019-02-13Merge branch 'js/mingw-host-cpu'Libravatar Junio C Hamano1-0/+2
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/+2
* 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-0/+2
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-13config.mak.uname: move location of bash on NonStop to CoreUtilsLibravatar Randall S. Becker1-3/+1
The default bash is now officially in /usr/coreutils/bin instead of in /usr/local/bin. This version of bash is more stable and recommended for all use as of the J06.22 and L18.02 operating system revision levels. This new version provides more stability of test results. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> 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/+2
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-11config.mak.uname: add FREAD_READS_DIRECTORIES for NonStop platformLibravatar Randall S. Becker1-0/+1
The NonStop platform needs this configuration item specified as UnfortunatelyYes so that config directory files are correctly processed. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-06Merge branch 'rj/sparse-flags'Libravatar Junio C Hamano1-1/+0
Use of the sparse tool got easier to customize from the command line to help developers. * rj/sparse-flags: Makefile: improve SPARSE_FLAGS customisation config.mak.uname: remove obsolete SPARSE_FLAGS setting
2019-02-05config.mak.uname: remove obsolete SPARSE_FLAGS settingLibravatar Ramsay Jones1-1/+0
An upcoming commit will change the semantics of the SPARSE_FLAGS variable from an internal to a user only customisation variable. The MinGW configuration section contains an obsolete setting for this variable which was used (some years ago) to cater to an error in the Win32 system header files. Since 'sparse' does not currently support the MinGW platform, nobody on that platform can be relying on this setting today. Remove this use of the SPARSE_FLAGS variable. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Acked-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-6/+23
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-14Merge branch 'tb/use-common-win32-pathfuncs-on-cygwin'Libravatar Junio C Hamano1-1/+2
Cygwin update. * tb/use-common-win32-pathfuncs-on-cygwin: git clone <url> C:\cygwin\home\USER\repo' is working (again)
2019-01-14Merge branch 'cb/openbsd-allows-reading-directory'Libravatar Junio C Hamano1-0/+1
BSD port update. * cb/openbsd-allows-reading-directory: config.mak.uname: OpenBSD uses BSD semantics with fread for directories
2019-01-03config.mak.uname: support for modern HPE NonStop config.Libravatar Randall S. Becker1-6/+23
A number of configuration options are not automatically detected by configure mechanisms, including the location of Perl and Python. There was a problem at a specific set of operating system versions that caused getopt to have compile errors. Account for this by providing emulation defines for those versions. 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ögershausen1-1/+2
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-03config.mak.uname: OpenBSD uses BSD semantics with fread for directoriesLibravatar Carlo Marcelo Arenas Belón1-0/+1
this "fixes" test 23 (proper error on directory "files") from t1308 MirBSD likely also affected but this was only tested with OpenBSD and therefore this specific change only affects that platform the optional 'configure' sets this automatically (tested with 6.1 to 6.4) but considering this is a legacy feature it is likely that it affected all old versions and is probably what most users had been using as a workaround Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-18Merge branch 'jk/curl-ldflags'Libravatar Junio C Hamano1-3/+0
The way -lcurl library gets linked has been simplified by taking advantage of the fact that we can just ask curl-config command how. * jk/curl-ldflags: build: link with curl-defined linker flags
2018-11-05build: link with curl-defined linker flagsLibravatar James Knight1-3/+0
Adjusting the build process to rely more on curl-config to populate linker flags instead of manually populating flags based off detected features. Originally, a configure-invoked build would check for SSL-support in the target curl library. If enabled, NEEDS_SSL_WITH_CURL would be set and used in the Makefile to append additional libraries to link against. As for systems building solely with make, the defines NEEDS_IDN_WITH_CURL and NEEDS_SSL_WITH_CURL could be set to indirectly enable respective linker flags. Since both configure.ac and Makefile already rely on curl-config utility to provide curl-related build information, adjusting the respective assets to populate required linker flags using the utility (unless explicitly configured). Signed-off-by: James Knight <james.d.knight@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-24mingw: implement nanosecond-precision file timesLibravatar Karsten Blees1-2/+0
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 <blees@dcon.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-04mingw: bump the minimum Windows version to VistaLibravatar Johannes Schindelin1-4/+0
Quite some time ago, a last plea to the XP users out there who want to see Windows XP support in Git for Windows, asking them to get engaged and help, vanished into the depths of the universe. We tried for a long time to play nice with the last remaining XP users who somehow manage to build Git from source, but a recent update of mingw-w64 (7.0.0.5233.e0c09544 -> 7.0.0.5245.edf66197) finally dropped the last sign of XP support, and Git for Windows' SDK is no longer able to build core Git's `master` branch as a consequence. (Git for Windows' `master` branch already bumped the minimum Windows version to Vista a while ago, so it is fine.) It is time to require Windows Vista or later to build Git from source. This, incidentally, lets us use quite a few nice new APIs. It also means that we no longer need the inet_pton() and inet_ntop() emulation, which is nice. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-04Merge branch 'es/freebsd-iconv-portability'Libravatar Junio C Hamano1-1/+11
Build fix. * es/freebsd-iconv-portability: config.mak.uname: resolve FreeBSD iconv-related compilation warning
2018-08-31config.mak.uname: resolve FreeBSD iconv-related compilation warningLibravatar Eric Sunshine1-1/+11
OLD_ICONV has long been needed by FreeBSD so config.mak.uname defines it unconditionally. However, recent versions do not need it, and its presence results in compilation warnings. Resolve this issue by defining OLD_ICONV only for older FreeBSD versions. Specifically, revision r281550[1], which is part of FreeBSD 11, removed the need for OLD_ICONV, and r282275[2] back-ported that change to 10.2. Versions prior to 10.2 do need it. [1] https://github.com/freebsd/freebsd/commit/b0813ee288f64f677a2cebf7815754b027a8215b [2] https://github.com/freebsd/freebsd/commit/b709ec868adb5170d09bc5a66b18d0e0d5987ab6 [es: commit message; tweak version check to distinguish 10.x versions] Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-30mingw: define WIN32 explicitlyLibravatar Johannes Schindelin1-1/+1
This helps VS Code's intellisense to figure out that we want to include windows.h, and that we want to define the minimum target Windows version as Windows Vista/2008R2. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-23Merge branch 'nd/repack-keep-pack'Libravatar Junio C Hamano1-0/+1
"git gc" in a large repository takes a lot of time as it considers to repack all objects into one pack by default. The command has been taught to pretend as if the largest existing packfile is marked with ".keep" so that it is left untouched while objects in other packs and loose ones are repacked. * nd/repack-keep-pack: pack-objects: show some progress when counting kept objects gc --auto: exclude base pack if not enough mem to "repack -ad" gc: handle a corner case in gc.bigPackThreshold gc: add gc.bigPackThreshold config gc: add --keep-largest-pack option repack: add --keep-pack option t7700: have closing quote of a test at the beginning of line
2018-04-16gc --auto: exclude base pack if not enough mem to "repack -ad"Libravatar Nguyễn Thái Ngọc Duy1-0/+1
pack-objects could be a big memory hog especially on large repos, everybody knows that. The suggestion to stick a .keep file on the giant base pack to avoid this problem is also known for a long time. Recent patches add an option to do just this, but it has to be either configured or activated manually. This patch lets `git gc --auto` activate this mode automatically when it thinks `repack -ad` will use a lot of memory and start affecting the system due to swapping or flushing OS cache. gc --auto decides to do this based on an estimation of pack-objects memory usage, which is quite accurate at least for the heap part, and whether that fits in half of system memory (the assumption here is for desktop environment where there are many other applications running). This mechanism only kicks in if gc.bigBasePackThreshold is not configured. If it is, it is assumed that the user already knows what they want. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-11mingw/msvc: use the new-style RUNTIME_PREFIX helperLibravatar Johannes Schindelin1-0/+2
This change also allows us to stop overriding argv[0] with the absolute path of the executable, allowing us to preserve e.g. the case of the executable's file name. This fixes https://github.com/git-for-windows/git/issues/1496 partially. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-11exec_cmd: RUNTIME_PREFIX on some POSIX systemsLibravatar Dan Jacques1-0/+7
Enable Git to resolve its own binary location using a variety of OS-specific and generic methods, including: - procfs via "/proc/self/exe" (Linux) - _NSGetExecutablePath (Darwin) - KERN_PROC_PATHNAME sysctl on BSDs. - argv0, if absolute (all, including Windows). This is used to enable RUNTIME_PREFIX support for non-Windows systems, notably Linux and Darwin. When configured with RUNTIME_PREFIX, Git will do a best-effort resolution of its executable path and automatically use this as its "exec_path" for relative helper and data lookups, unless explicitly overridden. Small incidental formatting cleanup of "exec_cmd.c". Signed-off-by: Dan Jacques <dnj@google.com> Thanks-to: Robbie Iannucci <iannucci@google.com> Thanks-to: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>