1. 03 Oct, 2019 1 commit
  2. 21 May, 2019 6 commits
  3. 20 May, 2019 2 commits
  4. 19 May, 2019 2 commits
  5. 12 May, 2019 4 commits
  6. 10 May, 2019 1 commit
  7. 06 May, 2019 1 commit
  8. 05 May, 2019 1 commit
  9. 03 May, 2019 1 commit
  10. 02 May, 2019 4 commits
    • Merge pull request #5063 from pks-t/pks/cmake-regcomp-fix · 604e2811
      cmake: correctly detect if system provides `regcomp`
      Patrick Steinhardt committed
    • Merge pull request #5023 from ianhattendorf/fix/lock_missing_global_config · 957940bf
      Correctly write to missing locked global config
      Patrick Steinhardt committed
    • cmake: fix include ordering issues with bundled deps · ee3d71fb
      When linking against bundled libraries, we include their header
      directories by using "-isystem". The reason for that is that we
      want to handle our vendored library headers specially, most
      importantly to ignore warnings generated by including them. By
      using "-isystem", though, we screw up the order of searched
      include directories by moving those bundled dependencies towards
      the end of the lookup order. Like this, chances are high that any
      other specified include directory contains a file that collides
      with the actual desired include file.
      
      Fix this by not treating the bundled dependencies' include
      directories as system includes. This will move them to the front
      of the lookup order and thus cause them to override
      system-provided headers. While this may cause the compiler to
      generate additional warnings when processing bundled headers,
      this is a tradeoff we should make regardless to fix builds on
      systems hitting this issue.
      Patrick Steinhardt committed
    • cmake: correctly detect if system provides `regcomp` · 13cb9f7a
      We assume that if we are on Win32, Amiga OS, Solaris or SunOS,
      that the regcomp(3P) function cannot be provided by the system.
      Thus we will in these cases always include our own, bundled regex
      sources to make a regcomp implementation available. This test is
      obviously very fragile, and we have seen it fail on MSYS2/MinGW
      systems, which do in fact provide the regcomp symbol. The effect
      is that during compilation, we will use the "regex.h" header
      provided by MinGW, but use symbols provided by ourselves. This
      in fact may cause subtle memory layout issues, as the structure
      made available via MinGW doesn't match what our bundled code
      expects.
      
      There's one more problem with our regex detection: on the listed
      platforms, we will incorrectly include the bundled regex code
      even in case where the system provides regcomp_l(3), but it will
      never be used for anything.
      
      Fix the issue by improving our regcomp detection code. Instead of
      relying on a fragile listing of platforms, we can just use
      `CHECK_FUNCTION_EXISTS` instead. This will not in fact avoid the
      header-ordering problem. But we can assume that as soon as a
      system-provided "regex.h" header is provided, that
      `CHECK_FUNCTION_EXISTS` will now correctly find the desired
      symbol and thus not include our bundled regex code.
      Patrick Steinhardt committed
  11. 30 Apr, 2019 1 commit
  12. 29 Apr, 2019 1 commit
  13. 26 Apr, 2019 1 commit
  14. 21 Apr, 2019 1 commit
    • rebase: orig_head and onto accessors · e215f475
      The rebase struct stores fields with information about the current
      rebase process, which were not accessible via a public interface.
      
      Accessors for getting the `orig_head` and `onto` branch
      names and object ids have been added.
      Erik Aigner committed
  15. 17 Apr, 2019 2 commits
    • Merge pull request #5050 from libgit2/ethomson/windows_init_traversal · b3923cf7
      git_repository_init: stop traversing at windows root
      Edward Thomson committed
    • git_repository_init: stop traversing at windows root · 45f24e78
      Stop traversing the filesystem at the Windows directory root.  We were
      calculating the filesystem root for the given directory to create, and
      walking up the filesystem hierarchy.  We intended to stop when the
      traversal path length is equal to the root path length (ie, stopping at
      the root, since no path may be shorter than the root path).
      
      However, on Windows, the root path may be specified in two different
      ways, as either `Z:` or `Z:\`, where `Z:` is the current drive letter.
      `git_path_dirname_r` returns the path _without_ a trailing slash, even
      for the Windows root.  As a result, during traversal, we need to test
      that the traversal path is _less than or equal to_ the root path length
      to determine if we've hit the root to ensure that we stop when our
      traversal path is `Z:` and our calculated root path was `Z:\`.
      Edward Thomson committed
  16. 16 Apr, 2019 11 commits