1. 15 Jun, 2017 1 commit
    • Jeff King's avatar
      configure.ac: loosen FREAD_READS_DIRECTORIES test program · 3adf9fde
      Jeff King authored
      We added an FREAD_READS_DIRECTORIES Makefile knob long ago
      in cba22528 (Add compat/fopen.c which returns NULL on
      attempt to open directory, 2008-02-08) to handle systems
      where reading from a directory returned garbage. This works
      by catching the problem at the fopen() stage and returning
      More recently, we found that there is a class of systems
      (including Linux) where fopen() succeeds but fread() fails.
      Since the solution is the same (having fopen return NULL),
      they use the same Makefile knob as of e2d90fd1
      (config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and
      FreeBSD, 2017-05-03).
      This works fine except for one thing: the autoconf test in
      configure.ac to set FREAD_READS_DIRECTORIES actually checks
      whether fread succeeds. Which means that on Linux systems,
      the knob isn't set (and we even override the config.mak.uname
      default). t1308 catches the failure.
      We can fix this by tweaking the autoconf test to cover both
      cases. In theory we might care about the distinction between
      the traditional "fread reads directories" case and the new
      "fopen opens directories". But since our solution catches
      the problem at the fopen stage either way, we don't actually
      need to know the difference. The "fopen" case is a superset.
      This does mean the FREAD_READS_DIRECTORIES name is slightly
      misleading. Probably FOPEN_OPENS_DIRECTORIES would be more
      accurate. But it would be disruptive to simply change the
      name (people's existing build configs would fail), and it's
      not worth the complexity of handling both. Let's just add a
      comment in the knob description.
      Reported-by: Øyvind A. Holm's avatarØyvind A. Holm <sunny@sunbase.org>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  2. 01 Jun, 2017 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      grep: add support for PCRE v2 · 94da9193
      Ævar Arnfjörð Bjarmason authored
      Add support for v2 of the PCRE API. This is a new major version of
      PCRE that came out in early 2015[1].
      The regular expression syntax is the same, but while the API is
      similar, pretty much every function is either renamed or takes
      different arguments. Thus using it via entirely new functions makes
      sense, as opposed to trying to e.g. have one compile_pcre_pattern()
      that would call either PCRE v1 or v2 functions.
      Git can now be compiled with either USE_LIBPCRE1=YesPlease or
      USE_LIBPCRE2=YesPlease, with USE_LIBPCRE=YesPlease currently being a
      synonym for the former. Providing both is a compile-time error.
      With earlier patches to enable JIT for PCRE v1 the performance of the
      release versions of both libraries is almost exactly the same, with
      PCRE v2 being around 1% slower.
      However after I reported this to the pcre-dev mailing list[2] I got a
      lot of help with the API use from Zoltán Herczeg, he subsequently
      optimized some of the JIT functionality in v2 of the library.
      Running the p7820-grep-engines.sh performance test against the latest
      Subversion trunk of both, with both them and git compiled as -O3, and
      the test run against linux.git, gives the following results. Just the
      /perl/ tests shown:
          $ GIT_PERF_REPEAT_COUNT=30 GIT_PERF_LARGE_REPO=~/g/linux GIT_PERF_MAKE_COMMAND='grep -q LIBPCRE2 Makefile && make -j8 USE_LIBPCRE2=YesPlease CC=~/perl5/installed/bin/gcc NO_R_TO_GCC_LINKER=YesPlease CFLAGS=-O3 LIBPCREDIR=/home/avar/g/pcre2/inst LDFLAGS=-Wl,-rpath,/home/avar/g/pcre2/inst/lib || make -j8 USE_LIBPCRE=YesPlease CC=~/perl5/installed/bin/gcc NO_R_TO_GCC_LINKER=YesPlease CFLAGS=-O3 LIBPCREDIR=/home/avar/g/pcre/inst LDFLAGS=-Wl,-rpath,/home/avar/g/pcre/inst/lib' ./run HEAD~5 HEAD~ HEAD p7820-grep-engines.sh
          Test                                            HEAD~5            HEAD~                    HEAD
          7820.3: perl grep 'how.to'                      0.31(1.10+0.48)   0.21(0.35+0.56) -32.3%   0.21(0.34+0.55) -32.3%
          7820.7: perl grep '^how to'                     0.56(2.70+0.40)   0.24(0.64+0.52) -57.1%   0.20(0.28+0.60) -64.3%
          7820.11: perl grep '[how] to'                   0.56(2.66+0.38)   0.29(0.95+0.45) -48.2%   0.23(0.45+0.54) -58.9%
          7820.15: perl grep '(e.t[^ ]*|v.ry) rare'       1.02(5.77+0.42)   0.31(1.02+0.54) -69.6%   0.23(0.50+0.54) -77.5%
          7820.19: perl grep 'm(ú|u)lt.b(æ|y)te'          0.38(1.57+0.42)   0.27(0.85+0.46) -28.9%   0.21(0.33+0.57) -44.7%
      See commit ("perf: add a comparison test of grep regex engines",
      2017-04-19) for details on the machine the above test run was executed
      Here HEAD~2 is git with PCRE v1 without JIT, HEAD~ is PCRE v1 with
      JIT, and HEAD is PCRE v2 (also with JIT). See previous commits of mine
      mentioning p7820-grep-engines.sh for more details on the test setup.
      For ease of readability, a different run just of HEAD~ (PCRE v1 with
      JIT v.s. PCRE v2), again with just the /perl/ tests shown:
          Test                                            HEAD~             HEAD
          7820.3: perl grep 'how.to'                      0.21(0.42+0.52)   0.21(0.31+0.58) +0.0%
          7820.7: perl grep '^how to'                     0.25(0.65+0.50)   0.20(0.31+0.57) -20.0%
          7820.11: perl grep '[how] to'                   0.30(0.90+0.50)   0.23(0.46+0.53) -23.3%
          7820.15: perl grep '(e.t[^ ]*|v.ry) rare'       0.30(1.19+0.38)   0.23(0.51+0.51) -23.3%
          7820.19: perl grep 'm(ú|u)lt.b(æ|y)te'          0.27(0.84+0.48)   0.21(0.34+0.57) -22.2%
      I.e. the two are either neck-to-neck, but PCRE v2 usually pulls ahead,
      when it does it's around 20% faster.
      A brief note on thread safety: As noted in pcre2api(3) & pcre2jit(3)
      the compiled pattern can be shared between threads, but not some of
      the JIT context, however the grep threading support does all pattern &
      JIT compilation in separate threads, so this code doesn't need to
      concern itself with thread safety.
      See commit 63e7e9d8 ("git-grep: Learn PCRE", 2011-05-09) for the
      initial addition of PCRE v1. This change follows some of the same
      patterns it did (and which were discussed on list at the time),
      e.g. mocking up types with typedef instead of ifdef-ing them out when
      USE_LIBPCRE2 isn't defined. This adds some trivial memory use to the
      program, but makes the code look nicer.
      1. https://lists.exim.org/lurker/message/20150105.162835.0666407a.en.html
      2. https://lists.exim.org/lurker/thread/20170419.172322.833ee099.en.htmlSigned-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  3. 20 May, 2017 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      Makefile & configure: reword inaccurate comment about PCRE · 072473e6
      Ævar Arnfjörð Bjarmason authored
      Reword an outdated & inaccurate comment which suggests that only
      git-grep can use PCRE.
      This comment was added back when PCRE support was initially added in
      commit 63e7e9d8 ("git-grep: Learn PCRE", 2011-05-09), and was true
      at the time.
      It hasn't been telling the full truth since git-log learned to use
      PCRE with --grep in commit 727b6fc3 ("log --grep: accept
      --basic-regexp and --perl-regexp", 2012-10-03), and more importantly
      is likely to get more inaccurate over time as more use is made of PCRE
      in other areas.
      Reword it to be more future-proof, and to more clearly explain that
      this enables user-initiated runtime behavior.
      Copy/pasting this so much in configure.ac is lame, these Makefile-like
      flags aren't even used by autoconf, just the corresponding
      --with[out]-* options. But copy/pasting the comments that make sense
      for the Makefile to configure.ac where they make less sense is the
      pattern everything else follows in that file. I'm not going to war
      against that as part of this change, just following the existing
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  4. 28 Feb, 2017 1 commit
  5. 10 Oct, 2016 1 commit
  6. 18 Jul, 2016 1 commit
  7. 28 Jun, 2016 1 commit
  8. 08 Apr, 2016 1 commit
  9. 10 Mar, 2016 1 commit
    • Junio C Hamano's avatar
      sane_grep: pass "-a" if grep accepts it · 71b40103
      Junio C Hamano authored
      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: default avatarJunio C Hamano <gitster@pobox.com>
  10. 06 Nov, 2015 1 commit
  11. 21 Oct, 2015 2 commits
    • Remi Pommarel's avatar
      configure.ac: detect ssl need with libcurl · 7e91e8d7
      Remi Pommarel authored
      When libcurl has been statically compiled with openssl support they both
      need to be linked in everytime libcurl is used.
      During configuration this can be detected by looking for Curl_ssl_init
      function symbol in libcurl, which will only be present if libcurl has been
      compiled statically built with openssl.
      configure.ac checks for Curl_ssl_init function in libcurl and if such function
      exists; it sets NEEDS_SSL_WITH_CURL that is used by the Makefile to include
      -lssl alongside with -lcurl.
      Signed-off-by: Remi Pommarel's avatarRemi Pommarel <repk@triplefau.lt>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Remi Pommarel's avatar
      Makefile: make curl-config path configurable · f8915876
      Remi Pommarel authored
      There are situations, e.g. during cross compilation, where curl-config
      program is not present in the PATH.
      Make the makefile use a configurable curl-config program passed through
      CURL_CONFIG variable which can be set through config.mak.
      Also make this variable tunable through use of autoconf/configure. Configure
      will set CURL_CONFIG variable in config.mak.autogen to whatever value has been
      passed to ac_cv_prog_CURL_CONFIG.
      Signed-off-by: Remi Pommarel's avatarRemi Pommarel <repk@triplefau.lt>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  12. 05 Oct, 2015 1 commit
  13. 03 Jun, 2015 1 commit
  14. 10 Mar, 2015 1 commit
  15. 09 Jan, 2015 3 commits
  16. 04 Dec, 2014 1 commit
    • David Michael's avatar
      compat: convert modes to use portable file type values · d543d9c0
      David Michael authored
      This adds simple wrapper functions around calls to stat(), fstat(),
      and lstat() that translate the operating system's native file type
      bits to those used by most operating systems.  It also rewrites the
      S_IF* macros to the common values, so all file type processing is
      performed using the translated modes.  This makes projects portable
      across operating systems that use different file type definitions.
      Only the file type bits may be affected by these compatibility
      functions; the file permission bits are assumed to be 07777 and are
      passed through unchanged.
      Signed-off-by: default avatarDavid Michael <fedora.dm0@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  17. 29 Aug, 2014 2 commits
  18. 27 Mar, 2014 1 commit
    • Kirill Smelkov's avatar
      Portable alloca for Git · 61f76a36
      Kirill Smelkov authored
      In the next patch we'll have to use alloca() for performance reasons,
      but since alloca is non-standardized and is not portable, let's have a
      trick with compatibility wrappers:
      1. at configure time, determine, do we have working alloca() through
         alloca.h, and define
          #define HAVE_ALLOCA_H
         if yes.
      2. in code
          #ifdef HAVE_ALLOCA_H
          # include <alloca.h>
          # define xalloca(size)      (alloca(size))
          # define xalloca_free(p)    do {} while(0)
          # define xalloca(size)      (xmalloc(size))
          # define xalloca_free(p)    (free(p))
         and use it like
         func() {
             p = xalloca(size);
      This way, for systems, where alloca is available, we'll have optimal
      on-stack allocations with fast executions. On the other hand, on
      systems, where alloca is not available, this gracefully fallbacks to
      Both autoconf and config.mak.uname configurations were updated. For
      autoconf, we are not bothering considering cases, when no alloca.h is
      available, but alloca() works some other way - its simply alloca.h is
      available and works or not, everything else is deep legacy.
      For config.mak.uname, I've tried to make my almost-sure guess for where
      alloca() is available, but since I only have access to Linux it is the
      only change I can be sure about myself, with relevant to other changed
      systems people Cc'ed.
      SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations.
      I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be
      Cc: Brandon Casey <drafnel@gmail.com>
      Cc: Marius Storm-Olsen <mstormo@gmail.com>
      Cc: Johannes Sixt <j6t@kdbg.org>
      Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
      Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
      Cc: Gerrit Pape <pape@smarden.org>
      Cc: Petr Salinger <Petr.Salinger@seznam.cz>
      Cc: Jonathan Nieder <jrnieder@gmail.com>
      Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes)
      Signed-off-by: default avatarKirill Smelkov <kirr@mns.spb.ru>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  19. 11 Mar, 2014 1 commit
    • Dmitry Marakasov's avatar
      configure.ac: link with -liconv for locale_charset() · 62fb6d03
      Dmitry Marakasov authored
      On e.g. FreeBSD 10.x, the following situation is common:
      - there's iconv implementation in libc, which has no locale_charset()
      - there's GNU libiconv installed from Ports Collection
      Git build process
      - detects that iconv is in libc and thus -liconv is not needed for it
      - detects locale_charset in -liconv, but for some reason doesn't add it
        to CHARSET_LIB (as it would do with -lcharset if locale_charset() was
        found there instead of -liconv)
      - git doesn't build due to unresolved external locale_charset()
      Fix this by adding -liconv to CHARSET_LIB if locale_charset() is
      detected in this library.
      Signed-off-by: Dmitry Marakasov's avatarDmitry Marakasov <amdmi3@amdmi3.ru>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  20. 20 Feb, 2014 1 commit
  21. 28 Jun, 2013 1 commit
  22. 26 Feb, 2013 1 commit
  23. 20 Dec, 2012 1 commit
    • Junio C Hamano's avatar
      git-compat-util.h: do not #include <sys/param.h> by default · b2d05e06
      Junio C Hamano authored
      Earlier we allowed platforms that lack <sys/param.h> not to include
      the header file from git-compat-util.h; we have included this header
      file since the early days back when we used MAXPATHLEN (which we no
      longer use) and also depended on it slurping ULONG_MAX (which we get
      by including stdint.h or inttypes.h these days).
      It turns out that we can compile our modern codebase just file
      without including it on many platforms (so far, Fedora, Debian,
      Ubuntu, MinGW, Mac OS X, Cygwin, HP-Nonstop, QNX and z/OS are
      reported to be OK).
      Let's stop including it by default, and on platforms that need it to
      be included, leave "make NEEDS_SYS_PARAM_H=YesPlease" as an escape
      hatch and ask them to report to us, so that we can find out about
      the real dependency and fix it in a more platform agnostic way.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  24. 15 Dec, 2012 3 commits
  25. 28 Nov, 2012 1 commit
    • Max Horn's avatar
      configure.ac: fix pthreads detection on Mac OS X · e0a52279
      Max Horn authored
      The configure script checks whether certain flags are required to use
      pthreads. But it did not consider that *none* might be needed (as is the
      case on Mac OS X). This lead to configure adding "-mt" to the list of
      flags (which does nothing on OS X except producing a warning). This in
      turn triggered a compiler warning on every single file.
      To solve this, we now first check if pthreads work without extra flags.
      This means the check is now order dependant, hence a comment is added
      explaining this, and the reasons for it.
      Note that it might be possible to write an order independent test, but
      it does not seem worth the extra effort required for implementing and
      testing such a solution, when this simple solution exists and works.
      Signed-off-by: Max Horn's avatarMax Horn <max@quendi.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  26. 25 Oct, 2012 1 commit
  27. 09 Oct, 2012 1 commit
  28. 11 Sep, 2012 2 commits
  29. 19 Jul, 2012 5 commits