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. 18 Jul, 2019 1 commit
  4. 14 Jun, 2019 1 commit
    • Rename opt init functions to `options_init` · 0b5ba0d7
      In libgit2 nomenclature, when we need to verb a direct object, we name
      a function `git_directobject_verb`.  Thus, if we need to init an options
      structure named `git_foo_options`, then the name of the function that
      does that should be `git_foo_options_init`.
      
      The previous names of `git_foo_init_options` is close - it _sounds_ as
      if it's initializing the options of a `foo`, but in fact
      `git_foo_options` is its own noun that should be respected.
      
      Deprecate the old names; they'll now call directly to the new ones.
      Edward Thomson committed
  5. 01 Dec, 2018 1 commit
  6. 20 Oct, 2018 2 commits
    • checkout tests: test symlinks based on support, not platform · e4ac4000
      When testing whether symlinks are correctly checked out, examine the
      `core.symlinks` configuration option to determine if symlinks are
      supported in a repository, don't simply assume that Windows means that
      symbolic links are not supported.
      
      Further, when testing the expected default behavior of `core.symlinks`,
      test the filesystem's support to determine if symlinks are supported.
      
      Finally, ensure that `core.symlinks=true` fails on a system where
      symlinks are actually not supported.  This aligns with the behavior of
      Git for Windows.
      Edward Thomson committed
    • checkout tests: don't use GetFinalPathNameByHandle · 7b6875f4
      To determine the canonical filename for a given path, we previously
      looked at the directory entries on POSIX systems and used
      GetFinalPathNameByHandle on Windows.  However, GetFinalPathNameByHandle
      requires a HANDLE - the results of CreateFile - and you cannot
      CreateFile on a symbolic link.
      
      To support finding the canonical path of a symbolic link, simply use the
      existing POSIX code to look at the directory entries.
      Edward Thomson committed
  7. 10 Jun, 2018 1 commit
  8. 12 Jun, 2015 1 commit
  9. 04 May, 2015 3 commits
  10. 16 Mar, 2015 1 commit
  11. 20 Jan, 2015 3 commits