1. 24 Jun, 2019 5 commits
    • hash: move SHA1 implementations to its own hashing context · 8832172e
      Create a separate `git_hash_sha1_ctx` structure that is specific
      to the SHA1 implementation and move all SHA1 functions over to
      use that one instead of the generic `git_hash_ctx`. The
      `git_hash_ctx` for now simply has a union containing this single
      SHA1 implementation, only, without any mechanism to distinguish
      between different algortihms.
      Patrick Steinhardt committed
    • hash: split into generic and SHA1-specific interface · d46d3b53
      As a preparatory step to allow multiple hashing APIs to exist at
      the same time, split the hashing functions into one layer for generic
      hashing and one layer for SHA1-specific hashing. Right now, this is
      simply an additional indirection layer that doesn't yet serve any
      purpose. In the future, the generic API will be extended to allow for
      choosing which hash to use, though, by simply passing an enum to the
      hash context initialization function. This is necessary as a first step
      to be ready for Git's move to SHA256.
      Patrick Steinhardt committed
    • hash: move SHA1 implementations into 'sha1/' folder · fda20622
      As we will include additional hash algorithms in the future due
      to upstream git discussing a move away from SHA1, we should
      accomodate for that and prepare for the move. As a first step,
      move all SHA1 implementations into a common subdirectory.
      
      Also, create a SHA1-specific header file that lives inside the
      hash folder. This header will contain the SHA1-specific header
      includes, function declarations and the SHA1 context structure.
      Patrick Steinhardt committed
    • hash: introduce source files to break include circles · bd48bf3f
      The hash source files have circular include dependencies right
      now, which shows by our broken generic hash implementation. The
      "hash.h" header declares two functions and the `git_hash_ctx`
      typedef before actually including the hash backend header and can
      only declare the remaining hash functions after the include due
      to possibly static function declarations inside of the
      implementation includes.
      
      Let's break this cycle and help maintainability by creating a
      real implementation file for each of the hash implementations.
      Instead of relying on the exact include order, we now especially
      avoid the use of `GIT_INLINE` for function declarations.
      Patrick Steinhardt committed
    • hash: move `git_hash_prov` into Win32 backend · bbf034ab
      The structure `git_hash_prov` is only ever used by the Win32 SHA1
      backend. As such, it doesn't make much sense to expose it via the
      generic "hash.h" header, as it is an implementation detail of the Win32
      backend only. Move the typedef of `git_hash_prov` into
      "hash/sha1/win32.h" to fix this.
      Patrick Steinhardt committed
  2. 16 Jun, 2019 1 commit
  3. 15 Jun, 2019 13 commits
  4. 14 Jun, 2019 4 commits
    • 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
    • cmake: Modulize our TLS & hash detection · 94fc83b6
      The interactions between `USE_HTTPS` and `SHA1_BACKEND` have been
      streamlined. Previously we would have accepted not quite working
      configurations (like, `-DUSE_HTTPS=OFF -DSHA1_BACKEND=OpenSSL`) and, as
      the OpenSSL detection only ran with `USE_HTTPS`, the link would fail.
      
      The detection was moved to a new `USE_SHA1`, modeled after `USE_HTTPS`,
      which takes the values "CollisionDetection/Backend/Generic", to better
      match how the "hashing backend" is selected, the default (ON) being
      "CollisionDetection".
      
      Note that, as `SHA1_BACKEND` is still used internally, you might need to
      check what customization you're using it for.
      Etienne Samson committed
    • 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. 13 Jun, 2019 6 commits
    • http-parser: use our bundled http-parser by default · fb529a01
      Our bundled http-parser includes bugfixes, therefore we should prefer
      our http-parser until such time as we can identify that the system
      http-parser has these bugfixes (using a version check).
      
      Since these bugs are - at present - minor, retain the ability for users
      to force that they want to use the system http-parser anyway.  This does
      change the cmake specification so that people _must_ opt-in to the new
      behavior knowingly.
      Edward Thomson committed
    • attr_file: remove invalid TODO comment · 3b517351
      In our attributes pattern parsing code, we have a comment that
      states we might have to convert '\' characters to '/' to have
      proper POSIX paths. But in fact, '\' characters are valid inside
      the string and act as escape mechanism for various characters,
      which is why we never want to convert those to POSIX directory
      separators. Furthermore, gitignore patterns are specified to only
      treat '/' as directory separators.
      
      Remove the comment to avoid future confusion.
      Patrick Steinhardt committed
    • attr_file: account for escaped escapes when searching trailing space · b3b6a39d
      When determining the trailing space length, we need to honor
      whether spaces are escaped or not. Currently, we do not check
      whether the escape itself is escaped, though, which might
      generate an off-by-one in that case as we will simply treat the
      space as escaped.
      
      Fix this by checking whether the backslashes preceding the space
      are themselves escaped.
      Patrick Steinhardt committed
    • attr_file: fix unescaping of escapes required for fnmatch · 10ac298c
      When parsing attribute patterns, we will eventually unescape the
      parsed pattern. This is required because we require custom
      escapes for whitespace characters, as normally they are used to
      terminate the current pattern. Thing is, we don't only unescape
      those whitespace characters, but in fact all escaped sequences.
      So for example if the pattern was "\*", we unescape that to "*".
      As this is directly passed to fnmatch(3) later, fnmatch would
      treat it as a simple glob matching all files where it should
      instead only match a file with name "*".
      
      Fix the issue by unescaping spaces, only. Add a bunch of tests to
      exercise escape parsing.
      Patrick Steinhardt committed
    • attr_file: properly handle escaped '\' when searching non-escaped spaces · eb146e58
      When parsing attributes, we need to search for the first
      unescaped whitespace character to determine where the pattern is
      to be cut off. The scan fails to account for the case where the
      escaping '\' character is itself escaped, though, and thus we
      would not recognize the cut-off point in patterns like "\\ ".
      
      Refactor the scanning loop to remember whether the last character
      was an escape character. If it was and the next character is a
      '\', too, then we will reset to non-escaped mode again. Thus, we
      now handle escaped whitespaces as well as escaped wildcards
      correctly.
      Patrick Steinhardt committed
    • path: only treat paths starting with '\' as absolute on Win32 · f7c6795f
      Windows-based systems treat paths starting with '\' as absolute,
      either referring to the current drive's root (e.g. "\foo" might
      refer to "C:\foo") or to a network path (e.g. "\\host\foo"). On
      the other hand, (most?) systems that are not based on Win32
      accept backslashes as valid characters that may be part of the
      filename, and thus we cannot treat them to identify absolute
      paths.
      
      Change the logic to only paths starting with '\' as absolute on
      the Win32 platform. Add tests to avoid regressions and document
      behaviour.
      Patrick Steinhardt committed
  6. 11 Jun, 2019 1 commit
  7. 10 Jun, 2019 10 commits