1. 23 Feb, 2022 2 commits
  2. 09 Feb, 2022 1 commit
  3. 05 Jan, 2022 1 commit
  4. 09 Nov, 2021 2 commits
  5. 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
  6. 25 Sep, 2021 1 commit
  7. 09 Sep, 2021 1 commit
  8. 08 Aug, 2021 1 commit
  9. 30 Dec, 2020 1 commit
  10. 11 Oct, 2020 1 commit
  11. 10 Mar, 2020 1 commit
    • win32: don't canonicalize symlink targets · 43d7a42b
      Don't canonicalize symlink targets; our win32 path canonicalization
      routines expect an absolute path.  In particular, using the path
      canonicalization routines for symlink targets (introduced in commit
      7d55bee6, "win32: fix relative symlinks pointing into dirs",
      2020-01-10).
      
      Now, use the utf8 -> utf16 relative path handling functions, so that
      paths like "../foo" will be translated to "..\foo".
      Edward Thomson committed
  12. 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
  13. 25 Nov, 2019 1 commit
  14. 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
    • win32: correctly unlink symlinks to directories · a00842c4
      When deleting a symlink on Windows, then the way to delete it depends on
      whether it is a directory symlink or a file symlink. In the first case,
      we need to use `DeleteFile`, in the second `RemoveDirectory`. Right now,
      `p_unlink` will only ever try to use `DeleteFile`, though, and thus fail
      to remove directory symlinks. This mismatches how unlink(3P) is expected
      to behave, though, as it shall remove any symlink disregarding whether
      it is a file or directory symlink.
      
      In order to correctly unlink a symlink, we thus need to check what kind
      of file this is. If we were to first query file attributes of every file
      upon calling `p_unlink`, then this would penalize the common case
      though. Instead, we can try to first delete the file with `DeleteFile`
      and only if the error returned is `ERROR_ACCESS_DENIED` will we query
      file attributes and determine whether it is a directory symlink to use
      `RemoveDirectory` instead.
      Patrick Steinhardt committed
    • fileops: rename to "futils.h" to match function signatures · e54343a4
      Our file utils functions all have a "futils" prefix, e.g.
      `git_futils_touch`. One would thus naturally guess that their
      definitions and implementation would live in files "futils.h" and
      "futils.c", respectively, but in fact they live in "fileops.h".
      
      Rename the files to match expectations.
      Patrick Steinhardt committed
  15. 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
  16. 20 May, 2019 1 commit
  17. 06 May, 2019 1 commit
  18. 05 May, 2019 1 commit
  19. 22 Feb, 2019 1 commit
  20. 30 Jan, 2019 1 commit
  21. 22 Jan, 2019 1 commit
  22. 06 Jan, 2019 1 commit
    • Fix a bunch of warnings · 7b453e7e
      This change fixes a bunch of warnings that were discovered by compiling
      with `clang -target=i386-pc-linux-gnu`. It turned out that the
      intrinsics were not necessarily being used in all platforms! Especially
      in GCC, since it does not support __has_builtin.
      
      Some more warnings were gleaned from the Windows build, but I stopped
      when I saw that some third-party dependencies (e.g. zlib) have warnings
      of their own, so we might never be able to enable -Werror there.
      lhchavez committed
  23. 20 Oct, 2018 2 commits
  24. 19 Oct, 2018 1 commit
    • win32: rename `git_win32__canonicalize_path` · b2e85f98
      The internal API `git_win32__canonicalize_path` is far, far too easily
      confused with the internal API `git_win32_path_canonicalize`.  The
      former removes the namespace prefix from a path (eg, given
      `\\?\C:\Temp\foo`, it returns `C:\Temp\foo`, and given
      `\\?\UNC\server\share`, it returns `\\server\share`).  As such, rename
      it to `git_win32_path_remove_namespace`.
      
      `git_win32_path_canonicalize` remains unchanged.
      Edward Thomson committed
  25. 13 Jul, 2018 1 commit
    • treewide: remove use of C++ style comments · 9994cd3f
      C++ style comment ("//") are not specified by the ISO C90 standard and
      thus do not conform to it. While libgit2 aims to conform to C90, we did
      not enforce it until now, which is why quite a lot of these
      non-conforming comments have snuck into our codebase. Do a tree-wide
      conversion of all C++ style comments to the supported C style comments
      to allow us enforcing strict C90 compliance in a later commit.
      Patrick Steinhardt committed
  26. 26 Jul, 2017 2 commits
  27. 03 Jul, 2017 1 commit
    • Make sure to always include "common.h" first · 0c7f49dd
      Next to including several files, our "common.h" header also declares
      various macros which are then used throughout the project. As such, we
      have to make sure to always include this file first in all
      implementation files. Otherwise, we might encounter problems or even
      silent behavioural differences due to macros or defines not being
      defined as they should be. So in fact, our header and implementation
      files should make sure to always include "common.h" first.
      
      This commit does so by establishing a common include pattern. Header
      files inside of "src" will now always include "common.h" as its first
      other file, separated by a newline from all the other includes to make
      it stand out as special. There are two cases for the implementation
      files. If they do have a matching header file, they will always include
      this one first, leading to "common.h" being transitively included as
      first file. If they do not have a matching header file, they instead
      include "common.h" as first file themselves.
      
      This fixes the outlined problems and will become our standard practice
      for header and source files inside of the "src/" from now on.
      Patrick Steinhardt committed
  28. 17 Apr, 2017 1 commit
  29. 05 Apr, 2017 1 commit
  30. 03 Apr, 2017 3 commits
  31. 02 Apr, 2017 2 commits