1. 05 Jan, 2022 1 commit
  2. 09 Nov, 2021 2 commits
  3. 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
  4. 25 Sep, 2021 1 commit
  5. 09 Sep, 2021 1 commit
  6. 25 Aug, 2021 1 commit
  7. 09 Aug, 2021 1 commit
    • Get Win32 builds to build · b060080e
      Previously, the location of `GIT_WARN_UNUSED_RESULT` was causing it to
      be included _after_ a bunch of other headers (namely `src/vector.h`),
      which broke the build.
      
      This change does two things:
      
      * Moves the `GIT_WARN_UNUSED_RESULT` above most of the `$include`s in
        `src/common.h`.
      * Stops including `vector.h` from `src/win32/path_w32.c` since the
        header itself does not use it.
      lhchavez committed
  8. 08 Aug, 2021 1 commit
  9. 07 Jul, 2021 2 commits
  10. 18 May, 2021 1 commit
  11. 05 May, 2021 1 commit
  12. 15 Feb, 2021 1 commit
  13. 30 Dec, 2020 1 commit
  14. 08 Dec, 2020 1 commit
  15. 27 Nov, 2020 1 commit
  16. 21 Nov, 2020 3 commits
  17. 12 Oct, 2020 1 commit
    • Make the Windows leak detection more robust · 4a0dceeb
      This change:
      
      * Increases MY_ROW_LIMIT to 2M, since it has been failing in #5595's
        tests since it's _super_ close to the limit.
      * Calls `git_repository_free()` on a `git_repository` that was being
        leaked only in Windows.
      * Marks the global `git_repository` on `tests/repo/init.c` as `NULL`
        after being freed to make any accidental access more noisy.
      * Uses `cl_assert_equal_i()` in `test_trace_windows_stacktrace__leaks`
        to make the test failures more actionable.
      * Renames the globals in `tests/repo/init.c` so that they don't start
        with an underscore.
      lhchavez committed
  18. 11 Oct, 2020 4 commits
  19. 01 Jul, 2020 3 commits
  20. 09 Jun, 2020 1 commit
  21. 10 Mar, 2020 2 commits
    • 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
    • win32: introduce relative path handling function · f2b114ba
      Add a function that takes a (possibly) relative UTF-8 path and emits a
      UTF-16 path with forward slashes translated to backslashes.  If the
      given path is, in fact, absolute, it will be translated to absolute path
      handling rules.
      Edward Thomson committed
  22. 08 Mar, 2020 1 commit
    • win32: clarify usage of path canonicalization funcs · fb7da154
      The path canonicalization functions on win32 are intended to
      canonicalize absolute paths; those with prefixes.  In other words,
      things start with drive letters (`C:\`), share names (`\\server\share`),
      or other prefixes (`\\?\`).
      
      This function removes leading `..` that occur after the prefix but
      before the directory/file portion (eg, turning `C:\..\..\..\foo` into
      `C:\foo`).  This translation is not appropriate for local paths.
      Edward Thomson committed
  23. 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
  24. 29 Nov, 2019 1 commit
    • global: convert to fiber-local storage to fix exit races · 5c6180b5
      On Windows platforms, we automatically clean up the thread-local storage
      upon detaching a thread via `DllMain()`. The thing is that this happens
      for every thread of applications that link against the libgit2 DLL, even
      those that don't have anything to do with libgit2 itself. As a result,
      we cannot assume that these unsuspecting threads make use of our
      `git_libgit2_init()` and `git_libgit2_shutdow()` reference counting,
      which may lead to racy situations:
      
          Thread 1                    Thread 2
      
          git_libgit2_shutdown()
                                      DllMain(DETACH_THREAD)
                                      git__free_tls_data()
          git_atomic_dec() == 0
          git__free_tls_data()
          TlsFree(_tls_index)
                                      TlsGetValue(_tls_index)
      
      Due to the second thread never having executed `git_libgit2_init()`, the
      first thread will clean up TLS data and as a result also free the
      `_tls_index` variable. When detaching the second thread, we
      unconditionally access the now-free'd `_tls_index` variable, which is
      obviously not going to work out well.
      
      Fix the issue by converting the code to use fiber-local storage instead
      of thread-local storage. While FLS will behave the exact same as TLS if
      no fibers are in use, it does allow us to specify a destructor similar
      to the one that is accepted by pthread_key_create(3P). Like this, we do
      not have to manually free indices anymore, but will let the FLS handle
      calling the destructor. This allows us to get rid of `DllMain()`
      completely, as we only used it to keep track of when threads were
      exiting and results in an overall simplification of TLS cleanup.
      Patrick Steinhardt committed
  25. 25 Nov, 2019 3 commits
  26. 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