summaryrefslogtreecommitdiff
path: root/config.mak.uname
AgeCommit message (Collapse)AuthorFilesLines
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>
2018-02-12config.mak.uname: remove SPARSE_FLAGS setting for cygwinLibravatar Ramsay Jones1-1/+0
Since commit f66450ae9 ("cygwin: Remove the Win32 l/stat() implementation", 2013-06-22), the cygwin build has not used the WIN32 API/header files. This means that the '-isystem /usr/include/w32api' option to sparse is no longer necessary (to allow sparse to find the WIN32 header files). In addition, the '-Wno-one-bit-signed-bitfield' option can be removed, since the warning suppressed by that option was only provoked by a WIN32 header file. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-25packed_ref_cache: keep the `packed-refs` file mmapped if possibleLibravatar Michael Haggerty1-0/+3
Keep a copy of the `packed-refs` file contents in memory for as long as a `packed_ref_cache` object is in use: * If the system allows it, keep the `packed-refs` file mmapped. * If not (either because the system doesn't support `mmap()` at all, or because a file that is currently mmapped cannot be replaced via `rename()`), then make a copy of the file's contents in heap-allocated space, and keep that around instead. We base the choice of behavior on a new build-time switch, `MMAP_PREVENTS_DELETE`. By default, this switch is set for Windows variants. After this commit, `MMAP_NONE` and `MMAP_TEMPORARY` are still handled identically. But the next commit will introduce a difference. This whole change is still pointless, because we only read the `packed-refs` file contents immediately after instantiating the `packed_ref_cache`. But that will soon change. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-21config.mak.uname: set FREAD_READS_DIRECTORIES for cygwinLibravatar Ramsay Jones1-0/+1
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-18Merge branch 'tb/push-to-cygwin-unc-path'Libravatar Junio C Hamano1-0/+1
On Cygwin, similar to Windows, "git push //server/share/repository" ought to mean a repository on a network share that can be accessed locally, but this did not work correctly due to stripping the double slashes at the beginning. This may need to be heavily tested before it gets unleashed to the wild, as the change is at a fairly low-level code and would affect not just the code to decide if the push destination is local. There may be unexpected fallouts in the path normalization. * tb/push-to-cygwin-unc-path: cygwin: allow pushing to UNC paths
2017-07-05cygwin: allow pushing to UNC pathsLibravatar Torsten Bögershausen1-0/+1
cygwin can use an UNC path like //server/share/repo $ cd //server/share/dir $ mkdir test $ cd test $ git init --bare However, when we try to push from a local Git repository to this repo, there is a problem: Git converts the leading "//" into a single "/". As cygwin handles an UNC path so well, Git can support them better: - Introduce cygwin_offset_1st_component() which keeps the leading "//", similar to what Git for Windows does. - Move CYGWIN out of the POSIX in the tests for path normalization in t0060 Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-19Merge branch 'ab/pcre-v2'Libravatar Junio C Hamano1-0/+1
Update "perl-compatible regular expression" support to enable JIT and also allow linking with the newer PCRE v2 library. * ab/pcre-v2: grep: add support for PCRE v2 grep: un-break building with PCRE >= 8.32 without --enable-jit grep: un-break building with PCRE < 8.20 grep: un-break building with PCRE < 8.32 grep: add support for the PCRE v1 JIT API log: add -P as a synonym for --perl-regexp grep: skip pthreads overhead when using one thread grep: don't redundantly compile throwaway patterns under threading
2017-06-13Merge branch 'nd/fopen-errors'Libravatar Junio C Hamano1-0/+4
We often try to open a file for reading whose existence is optional, and silently ignore errors from open/fopen; report such errors if they are not due to missing files. * nd/fopen-errors: mingw_fopen: report ENOENT for invalid file names mingw: verify that paths are not mistaken for remote nicknames log: fix memory leak in open_next_file() rerere.c: move error_errno() closer to the source system call print errno when reporting a system call error wrapper.c: make warn_on_inaccessible() static wrapper.c: add and use fopen_or_warn() wrapper.c: add and use warn_on_fopen_errors() config.mak.uname: set FREAD_READS_DIRECTORIES for Darwin, too config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and FreeBSD clone: use xfopen() instead of fopen() use xfopen() in more places git_fopen: fix a sparse 'not declared' warning
2017-06-02grep: un-break building with PCRE >= 8.32 without --enable-jitLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Amend my change earlier in this series ("grep: add support for the PCRE v1 JIT API", 2017-04-11) to un-break the build on PCRE v1 versions later than 8.31 compiled without --enable-jit. As explained in that change and a later compatibility change in this series ("grep: un-break building with PCRE < 8.32", 2017-05-10) the pcre_jit_exec() function is a faster path to execute the JIT. Unfortunately there's no compatibility stub for that function compiled into the library if pcre_config(PCRE_CONFIG_JIT, &ret) would return 0, and no macro that can be used to check for it, so the only portable option to support builds without --enable-jit is via a new NO_LIBPCRE1_JIT=UnfortunatelyYes Makefile option[1]. Another option would be to make the JIT opt-in via USE_LIBPCRE1_JIT=YesPlease, after all it's not a default option of PCRE v1. I think it makes more sense to make it opt-out since even though it's not a default option, most packagers of PCRE seem to turn it on by default, with the notable exception of the MinGW package. Make the MinGW platform work by default by changing the build defaults to turn on NO_LIBPCRE1_JIT=UnfortunatelyYes. It is the only platform that turns on USE_LIBPCRE=YesPlease by default, see commit df5218b4c3 ("config.mak.uname: support MSys2", 2016-01-13) for that change. 1. "How do I support pcre1 JIT on all versions?" (https://lists.exim.org/lurker/thread/20170601.103148.10253788.en.html) 2. https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-pcre/PKGBUILD (referenced from "Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)"; <alpine.DEB.2.20.1705021756530.3480@virtualbox>) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-26config.mak.uname: set FREAD_READS_DIRECTORIES for Darwin, tooLibravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-26config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and FreeBSDLibravatar Nguyễn Thái Ngọc Duy1-0/+3
This variable is added [1] with the assumption that on a sane system, fopen(<dir>, "r") should return NULL. Linux and FreeBSD do not meet this expectation while at least Windows and AIX do. Let's make sure they behave the same way. I only tested one version on Linux (4.7.0 with glibc 2.22) and FreeBSD (11.0) but since GNU/kFreeBSD is fbsd kernel with gnu userspace, I'm pretty sure it shares the same problem. [1] cba22528fa (Add compat/fopen.c which returns NULL on attempt to open directory - 2008-02-08) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-04config.mak.uname: set NO_REGEX=NeedsStartEnd on AIXLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Set the NO_REGEX=NeedsStartEnd Makefile flag by default on AIX. Since commit 2f8952250a ("regex: add regexec_buf() that can work on a non NUL-terminated string", 2016-09-21) git has errored out at compile-time if the regular expression library doesn't support REG_STARTEND. While looking through Google search results for the use of NO_REGEX I found a Chef recipe that set this on AIX[1], looking through the documentation for the latest version of AIX (7.2, released October 2015) shows that its regexec() doesn't have REG_STARTEND. 1. https://github.com/chef/omnibus-software/commit/e247e36761#diff-3df898345d670979b74acc0bf71d8c47 2. https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.basetrf2/regexec.htm Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-21Merge branch 'rj/remove-unused-mktemp' into maintLibravatar Junio C Hamano1-17/+0
Code cleanup. * rj/remove-unused-mktemp: wrapper.c: remove unused gitmkstemps() function wrapper.c: remove unused git_mkstemp() function
2017-03-16Merge branch 'jh/mingw-openssl-sha1' into maintLibravatar Junio C Hamano1-1/+0
Windows port wants to use OpenSSL's implementation of SHA-1 routines, so let them. * jh/mingw-openssl-sha1: mingw: use OpenSSL's SHA-1 routines
2017-03-12Merge branch 'jh/mingw-openssl-sha1'Libravatar Junio C Hamano1-1/+0
Windows port wants to use OpenSSL's implementation of SHA-1 routines, so let them. * jh/mingw-openssl-sha1: mingw: use OpenSSL's SHA-1 routines
2017-02-28wrapper.c: remove unused gitmkstemps() functionLibravatar Ramsay Jones1-17/+0
The last call to the mkstemps() function was removed in commit 659488326 ("wrapper.c: delete dead function git_mkstemps()", 22-04-2016). In order to support platforms without mkstemps(), this functionality was provided, along with a Makefile build variable (NO_MKSTEMPS), by the gitmkstemps() function. Remove the dead code, along with the defunct build machinery. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-09mingw: use OpenSSL's SHA-1 routinesLibravatar Jeff Hostetler1-1/+0
Use OpenSSL's SHA-1 routines rather than builtin block-sha1 routines. This improves performance on SHA1 operations on Intel processors. OpenSSL 1.0.2 has made considerable performance improvements and support the Intel hardware acceleration features. See: https://software.intel.com/en-us/articles/improving-openssl-performance https://software.intel.com/en-us/articles/intel-sha-extensions To test this I added/staged a single file in a gigantic repository having a 450MB index file. The code in read-cache.c verifies the header SHA as it reads the index and computes a new header SHA as it writes out the new index. Therefore, in this test the SHA code must process 900MB of data. Testing was done on an Intel I7-4770 CPU @ 3.40GHz (Intel64, Family 6, Model 60) CPU. The block-sha1 version averaged 5.27 seconds. The OpenSSL version averaged 4.50 seconds. ================================================================ $ echo xxx >> project.mk $ time /e/blk_sha/bin/git.exe add project.mk real 0m5.207s user 0m0.000s sys 0m0.250s $ echo xxx >> project.mk $ time /e/blk_sha/bin/git.exe add project.mk real 0m5.362s user 0m0.015s sys 0m0.234s $ echo xxx >> project.mk $ time /e/blk_sha/bin/git.exe add project.mk real 0m5.300s user 0m0.016s sys 0m0.250s $ echo xxx >> project.mk $ time /e/blk_sha/bin/git.exe add project.mk real 0m5.216s user 0m0.000s sys 0m0.250s ================================================================ $ echo xxx >> project.mk $ time /e/openssl/bin/git.exe add project.mk real 0m4.431s user 0m0.000s sys 0m0.250s $ echo xxx >> project.mk $ time /e/openssl/bin/git.exe add project.mk real 0m4.478s user 0m0.000s sys 0m0.265s $ echo xxx >> project.mk $ time /e/openssl/bin/git.exe add project.mk real 0m4.690s user 0m0.000s sys 0m0.250s $ echo xxx >> project.mk $ time /e/openssl/bin/git.exe add project.mk real 0m4.420s user 0m0.000s sys 0m0.234s ================================================================ 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>
2016-12-06xdiff: drop XDL_FAST_HASHLibravatar Jeff King1-3/+0
The xdiff code hashes every line of both sides of a diff, and then compares those hashes to find duplicates. The overall performance depends both on how fast we can compute the hashes, but also on how many hash collisions we see. The idea of XDL_FAST_HASH is to speed up the hash computation. But the generated hashes have worse collision behavior. This means that in some cases it speeds diffs up (running "git log -p" on git.git improves by ~8% with it), but in others it can slow things down. One pathological case saw over a 100x slowdown[1]. There may be a better hash function that covers both properties, but in the meantime we are better off with the original hash. It's slightly slower in the common case, but it has fewer surprising pathological cases. [1] http://public-inbox.org/git/20141222041944.GA441@peff.net/ Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-08Merge branch 'ew/build-time-pager-tweaks'Libravatar Junio C Hamano1-0/+1
The build procedure learned PAGER_ENV knob that lists what default environment variable settings to export for popular pagers. This mechanism is used to tweak the default settings to MORE on FreeBSD. * ew/build-time-pager-tweaks: pager: move pager-specific setup into the build
2016-08-04pager: move pager-specific setup into the buildLibravatar Eric Wong1-0/+1
Allowing PAGER_ENV to be set at build-time allows us to move pager-specific knowledge out of our build. This allows us to set a better default for FreeBSD more(1), which pretends not to understand ANSI color escapes if the MORE environment variable is left empty, but accepts the same variables as less(1) Originally-from: https://public-inbox.org/git/xmqq61piw4yf.fsf@gitster.dls.corp.google.com/ Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28Merge branch 'ew/find-perl-on-freebsd-in-local'Libravatar Junio C Hamano1-0/+1
Recent FreeBSD stopped making perl available at /usr/bin/perl; switch the default the built-in path to /usr/local/bin/perl on not too ancient FreeBSD releases. * ew/find-perl-on-freebsd-in-local: config.mak.uname: correct perl path on FreeBSD
2016-07-26config.mak.uname: correct perl path on FreeBSDLibravatar Nguyễn Thái Ngọc Duy1-0/+1
It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has been removed at least on FreeBSD 10.3. See [1] for more information. [1] https://svnweb.freebsd.org/ports/head/UPDATING?r1=386270&r2=386269&pathrev=386270&diff_format=c Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Helped-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-11config.mak.uname: define NEEDS_LIBRT under Linux, for nowLibravatar Eric Wong1-0/+2
My Debian wheezy LTS system is still on glibc 2.13; and LTS distros may use older glibc, still, so lets not unnecessarily break things out-of-the-box. We seem to assume Linux is using glibc in our Makefiles anyways, so I don't think this will introduce new breakage for users of alternative libc implementations. Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-26mingw: make isatty() recognize MSYS2's pseudo terminals (/dev/pty*)Libravatar Karsten Blees1-1/+2
MSYS2 emulates pseudo terminals via named pipes, and isatty() returns 0 for such file descriptors. Therefore, some interactive functionality (such as launching a pager, asking if a failed unlink should be repeated etc.) doesn't work when run in a terminal emulator that uses MSYS2's ptys (such as mintty). However, MSYS2 uses special names for its pty pipes ('msys-*-pty*'), which allows us to distinguish them from normal piped input / output. On startup, check if stdin / stdout / stderr are connected to such pipes using the NtQueryObject API from NTDll.dll. If the names match, adjust the flags in MSVCRT's ioinfo structure accordingly. 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>
2016-05-02Merge branch 'ad/cygwin-wants-rename' into maintLibravatar Junio C Hamano1-0/+1
On Cygwin, object creation uses the "create a temporary and then rename it to the final name" pattern, not "create a temporary, hardlink it to the final name and then unlink the temporary" pattern. This is necessary to use Git on Windows shared directories, and is already enabled for the MinGW and plain Windows builds. It also has been used in Cygwin packaged versions of Git for quite a while. See http://thread.gmane.org/gmane.comp.version-control.git/291853 ($gmane/275680, $gmane/291853). * ad/cygwin-wants-rename: config.mak.uname: Cygwin needs OBJECT_CREATION_USES_RENAMES
2016-03-21Merge branch 'tb/avoid-gcc-on-darwin-10-6'Libravatar Junio C Hamano1-3/+0
* tb/avoid-gcc-on-darwin-10-6: Revert "config.mak.uname: use clang for Mac OS X 10.6"
2016-03-21Revert "config.mak.uname: use clang for Mac OS X 10.6"Libravatar Eric Sunshine1-3/+0
This reverts commit 7b6daf8d2fee1a9866b1d4eddbfaa5dbc42c5dbb. Now that st_add4() has been patched to work around the gcc 4.2.x compiler crash, revert the sledge-hammer approach of forcing Mac OS X 10.6 to unconditionally use 'clang' rather than the default compiler (gcc). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-16Merge branch 'jc/sane-grep'Libravatar Junio C Hamano1-0/+1
Recent versions of GNU grep is pickier than before to decide if a file is "binary" and refuse to give line-oriented hits when we expect it to, unless explicitly told with "-a" option. As our scripted Porcelains use sane_grep wrapper for line-oriented data, even when the line may contain non-ASCII payload we took from end-user data, use "grep -a" to implement sane_grep wrapper when using an implementation of "grep" that takes the "-a" option. * jc/sane-grep: rebase-i: clarify "is this commit relevant?" test sane_grep: pass "-a" if grep accepts it
2016-03-10sane_grep: pass "-a" if grep accepts itLibravatar Junio C Hamano1-0/+1
Newer versions of GNU grep is reported to be pickier when we feed a non-ASCII input and break some Porcelain scripts. As we know we do not feed random binary file to our own sane_grep wrapper, allow us to always pass "-a" by setting SANE_TEXT_GREP=-a Makefile variable to work it around. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-28config.mak.uname: use clang for Mac OS X 10.6Libravatar Torsten Bögershausen1-0/+3
Gcc under Mac OX 10.6 throws an internal compiler error: CC combine-diff.o combine-diff.c: In function ‘diff_tree_combined’: combine-diff.c:1391: internal compiler error: Segmentation fault while attempting to build Git at 5b442c4f (tree-diff: catch integer overflow in combine_diff_path allocation, 2016-02-19). As clang that ships with the version does not have the same bug, make Git compile under Mac OS X 10.6 by using clang instead of gcc to work this around, as it is unlikely that we will see fixed GCC on that platform. Later versions of Mac OSX/Xcode only provide clang, and gcc is a wrapper to it. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26mingw: do not trust MSYS2's MinGW gettext.shLibravatar Johannes Schindelin1-0/+1
It does not quite work because it produces DOS line endings which the shell does not like at all. This lets t0200-gettext-basic.sh, t0204-gettext-reencode-sanity.sh, t3406-rebase-message.sh, t3903-stash.sh, t7400-submodule-basic.sh, t7401-submodule-summary.sh, t7406-submodule-update.sh and t7407-submodule-foreach.sh pass in Git for Windows' SDK. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26mingw: let's use gettext with MSYS2Libravatar Johannes Schindelin1-1/+1
This solves two problems: - we now have proper localisation even on Windows - we sidestep the infamous "BUG: your vsnprintf is broken (returned -1)" message when running "git init" (which otherwise prevents the entire test suite from running) because libintl.h overrides vsnprintf() with libintl_vsnprintf() [*1*] The latter issue is rather crucial, as *no* test passes in Git for Windows without this fix. Footnote *1*: gettext_git=http://git.savannah.gnu.org/cgit/gettext.git $gettext_git/tree/gettext-runtime/intl/libgnuintl.in.h#n380 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13config.mak.uname: supporting 64-bit MSys2Libravatar Johannes Schindelin1-3/+11
This just makes things compile, the test suite needs extra tender loving care in addition to this change. We will address these issues in later commits. While at it, also allow building MSys2 Git (i.e. a Git that uses MSys2's POSIX emulation layer). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13config.mak.uname: support MSys2Libravatar Johannes Schindelin1-2/+19
For a long time, Git for Windows lagged behind Git's 2.x releases because the Git for Windows developers wanted to let that big jump coincide with a well-needed jump away from MSys to MSys2. To understand why this is such a big issue, it needs to be noted that many parts of Git are not written in portable C, but instead Git relies on a POSIX shell and Perl to be available. To support the scripts, Git for Windows has to ship a minimal POSIX emulation layer with Bash and Perl thrown in, and when the Git for Windows effort started in August 2007, this developer settled on using MSys, a stripped down version of Cygwin. Consequently, the original name of the project was "msysGit" (which, sadly, caused a *lot* of confusion because few Windows users know about MSys, and even less care). To compile the C code of Git for Windows, MSys was used, too: it sports two versions of the GNU C Compiler: one that links implicitly to the POSIX emulation layer, and another one that targets the plain Win32 API (with a few convenience functions thrown in). Git for Windows' executables are built using the latter, and therefore they are really just Win32 programs. To discern executables requiring the POSIX emulation layer from the ones that do not, the latter are called MinGW (Minimal GNU for Windows) when the former are called MSys executables. This reliance on MSys incurred challenges, too, though: some of our changes to the MSys runtime -- necessary to support Git for Windows better -- were not accepted upstream, so we had to maintain our own fork. Also, the MSys runtime was not developed further to support e.g. UTF-8 or 64-bit, and apart from lacking a package management system until much later (when mingw-get was introduced), many packages provided by the MSys/MinGW project lag behind the respective source code versions, in particular Bash and OpenSSL. For a while, the Git for Windows project tried to remedy the situation by trying to build newer versions of those packages, but the situation quickly became untenable, especially with problems like the Heartbleed bug requiring swift action that has nothing to do with developing Git for Windows further. Happily, in the meantime the MSys2 project (https://msys2.github.io/) emerged, and was chosen to be the base of the Git for Windows 2.x. Just like MSys, MSys2 is a stripped down version of Cygwin, but it is actively kept up-to-date with Cygwin's source code. Thereby, it already supports Unicode internally, and it also offers the 64-bit support that we yearned for since the beginning of the Git for Windows project. MSys2 also ported the Pacman package management system from Arch Linux and uses it heavily. This brings the same convenience to which Linux users are used to from `yum` or `apt-get`, and to which MacOSX users are used to from Homebrew or MacPorts, or BSD users from the Ports system, to MSys2: a simple `pacman -Syu` will update all installed packages to the newest versions currently available. MSys2 is also *very* active, typically providing package updates multiple times per week. It still required a two-month effort to bring everything to a state where Git's test suite passes, many more months until the first official Git for Windows 2.x was released, and a couple of patches still await their submission to the respective upstream projects. Yet without MSys2, the modernization of Git for Windows would simply not have happened. This commit lays the ground work to supporting MSys2-based Git builds. Assisted-by: Waldek Maleska <weakcamel@users.github.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>