1. 09 Nov, 2021 1 commit
  2. 17 Oct, 2021 1 commit
    • str: introduce `git_str` for internal, `git_buf` is external · f0e693b1
      libgit2 has two distinct requirements that were previously solved by
      `git_buf`.  We require:
      
      1. A general purpose string class that provides a number of utility APIs
         for manipulating data (eg, concatenating, truncating, etc).
      2. A structure that we can use to return strings to callers that they
         can take ownership of.
      
      By using a single class (`git_buf`) for both of these purposes, we have
      confused the API to the point that refactorings are difficult and
      reasoning about correctness is also difficult.
      
      Move the utility class `git_buf` to be called `git_str`: this represents
      its general purpose, as an internal string buffer class.  The name also
      is an homage to Junio Hamano ("gitstr").
      
      The public API remains `git_buf`, and has a much smaller footprint.  It
      is generally only used as an "out" param with strict requirements that
      follow the documentation.  (Exceptions exist for some legacy APIs to
      avoid breaking callers unnecessarily.)
      
      Utility functions exist to convert a user-specified `git_buf` to a
      `git_str` so that we can call internal functions, then converting it
      back again.
      Edward Thomson committed
  3. 10 Mar, 2020 1 commit
  4. 10 Jan, 2020 1 commit
    • win32: fix relative symlinks pointing into dirs · 7d55bee6
      On Windows platforms, we need some logic to emulate symlink(3P) defined
      by POSIX. As unprivileged symlinks on Windows are a rather new feature,
      our current implementation is comparatively new and still has some
      rough edges in special cases.
      
      One such case is relative symlinks. While relative symlinks to files in
      the same directory work as expected, libgit2 currently fails to create
      reltaive symlinks pointing into other directories. This is due to the
      fact that we forgot to translate the Unix-style target path to
      Windows-style. Most importantly, we are currently not converting
      directory separators from "/" to "\".
      
      Fix the issue by calling `git_win32_path_canonicalize` on the target.
      Add a test that verifies our ability to create such relative links
      across directories.
      Patrick Steinhardt committed
  5. 21 Sep, 2019 1 commit
  6. 20 Jul, 2019 3 commits
    • win32: fix symlinks to relative file targets · 50194dcd
      When creating a symlink in Windows, one needs to tell Windows whether
      the symlink should be a file or directory symlink. To determine which
      flag to pass, we call `GetFileAttributesW` on the target file to see
      whether it is a directory and then pass the flag accordingly. The
      problem though is if create a symlink with a relative target path, then
      we will check that relative path while not necessarily being inside of
      the working directory where the symlink is to be created. Thus, getting
      its attributes will either fail or return attributes of the wrong
      target.
      
      Fix this by resolving the target path relative to the directory in which
      the symlink is to be created.
      Patrick Steinhardt committed
    • tests: core: improve symlink test coverage · 93d37a1d
      Add two more tests to verify that we're not deleting symlink targets,
      but the symlinks themselves. Furthermore, convert several `cl_skip`s on
      Win32 to conditional skips depending on whether the clar sandbox
      supports symlinks or not. Windows is grown up now and may allow
      unprivileged symlinks if the machine has been configured accordingly.
      Patrick Steinhardt committed
    • tests: core: add missing asserts for several function calls · 683ea2b0
      Several function calls to `p_stat` and `p_close` have no verification if
      they actually succeeded. As these functions _may_ fail and as we also
      want to make sure that we're not doing anything dumb, let's check them,
      too.
      Patrick Steinhardt committed
  7. 14 Jun, 2019 1 commit
    • posix: remove `p_fallocate` abstraction · 2d85c7e8
      By now, we have repeatedly failed to provide a nice
      cross-platform implementation of `p_fallocate`. Recent tries to
      do that escalated quite fast to a set of different CMake checks,
      implementations, fallbacks, etc., which started to look real
      awkward to maintain. In fact, `p_fallocate` had only been
      introduced in commit 4e3949b7 (tests: test that largefiles can
      be read through the tree API, 2019-01-30) to support a test with
      large files, but given the maintenance costs it just seems not to
      be worht it.
      
      As we have removed the sole user of `p_fallocate` in the previous
      commit, let's drop it altogether.
      Patrick Steinhardt committed
  8. 19 May, 2019 8 commits
  9. 22 Feb, 2019 1 commit
  10. 22 Mar, 2017 1 commit
  11. 25 Feb, 2017 1 commit
  12. 07 Oct, 2016 1 commit
  13. 06 Oct, 2016 1 commit
  14. 12 Feb, 2016 1 commit
  15. 16 Jun, 2015 1 commit
  16. 14 Nov, 2013 1 commit
  17. 28 Aug, 2013 1 commit
  18. 24 Aug, 2013 1 commit
  19. 19 Aug, 2013 1 commit