1. 01 Jun, 2020 1 commit
  2. 23 May, 2020 1 commit
  3. 16 May, 2020 1 commit
  4. 12 May, 2020 1 commit
  5. 11 May, 2020 3 commits
    • assert: allow non-int returning functions to assert · cbae1c21
      Include GIT_ASSERT_WITH_RETVAL and GIT_ASSERT_ARG_WITH_RETVAL so that
      functions that do not return int (or more precisely, where `-1` would
      not be an error code) can assert.
      
      This allows functions that return, eg, NULL on an error code to do that
      by passing the return value (in this example, `NULL`) as a second
      parameter to the GIT_ASSERT_WITH_RETVAL functions.
      Edward Thomson committed
    • assert: optionally fall-back to assert(3) · a95096ba
      Fall back to the system assert(3) in debug builds, which may aide
      in debugging.
      
      "Safe" assertions can be enabled in debug builds by setting
      GIT_ASSERT_HARD=0.  Similarly, hard assertions can be enabled in
      release builds by setting GIT_ASSERT_HARD to nonzero.
      Edward Thomson committed
    • Introduce GIT_ASSERT macros · abe2efe1
      Provide macros to replace usages of `assert`.  A true `assert` is
      punishing as a library.  Instead we should do our best to not crash.
      
      GIT_ASSERT_ARG(x) will now assert that the given argument complies to
      some format and sets an error message and returns `-1` if it does not.
      
      GIT_ASSERT(x) is for internal usage, and available as an internal
      consistency check.  It will set an error message and return `-1` in the
      event of failure.
      Edward Thomson committed
  6. 10 May, 2020 3 commits
  7. 14 Apr, 2020 1 commit
  8. 03 Apr, 2020 1 commit
  9. 01 Apr, 2020 1 commit
    • merge: cache negative cache results for similarity metrics · 4dfcc50f
      When computing renames, we cache the hash signatures for each of the
      potentially conflicting entries so that we do not need to repeatedly
      read the file and can at least halfway efficiently determine whether two
      files are similar enough to be deemed a rename. In order to make the
      hash signatures meaningful, we require at least four lines of data to be
      present, resulting in at least four different hashes that can be
      compared. Files that are deemed too small are not cached at all and
      will thus be repeatedly re-hashed, which is usually not a huge issue.
      
      The issue with above heuristic is in case a file does _not_ have at
      least four lines, where a line is anything separated by a consecutive
      run of "\n" or "\0" characters. For example "a\nb" is two lines, but
      "a\0\0b" is also just two lines. Taken to the extreme, a file that has
      megabytes of consecutive space- or NUL-only may also be deemed as too
      small and thus not get cached. As a result, we will repeatedly load its
      blob, calculate its hash signature just to finally throw it away as we
      notice it's not of any value. When you've got a comparitively big file
      that you compare against a big set of potentially renamed files, then
      the cost simply expodes.
      
      The issue can be trivially fixed by introducing negative cache entries.
      Whenever we determine that a given blob does not have a meaningful
      representation via a hash signature, we store this negative cache marker
      and will from then on not hash it again, but also ignore it as a
      potential rename target. This should help the "normal" case already
      where you have a lot of small files as rename candidates, but in the
      above scenario it's savings are extraordinarily high.
      
      To verify we do not hit the issue anymore with described solution, this
      commit adds a test that uses the exact same setup described above with
      one 50 megabyte blob of '\0' characters and 1000 other files that get
      renamed. Without the negative cache:
      
      $ time ./libgit2_clar -smerge::trees::renames::cache_recomputation >/dev/null
      real    11m48.377s
      user    11m11.576s
      sys     0m35.187s
      
      And with the negative cache:
      
      $ time ./libgit2_clar -smerge::trees::renames::cache_recomputation >/dev/null
      real    0m1.972s
      user    0m1.851s
      sys     0m0.118s
      
      So this represents a ~350-fold performance improvement, but it obviously
      depends on how many files you have and how big the blob is. The test
      number were chosen in a way that one will immediately notice as soon as
      the bug resurfaces.
      Patrick Steinhardt committed
  10. 26 Mar, 2020 1 commit
    • patch: correctly handle mode changes for renames · 5f47cb48
      When generating a patch for a renamed file whose mode bits have changed
      in addition to the rename, then we currently fail to parse the generated
      patch. Furthermore, when generating a diff we output mode bits after the
      similarity metric, which is different to how upstream git handles it.
      
      Fix both issues by adding another state transition that allows
      similarity indices after mode changes and by printing mode changes
      before the similarity index.
      Patrick Steinhardt committed
  11. 23 Mar, 2020 1 commit
  12. 10 Mar, 2020 2 commits
  13. 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
  14. 18 Feb, 2020 1 commit
  15. 11 Feb, 2020 1 commit
    • repository: handle format v1 · 06f02300
      Git has supported repository format version 1 for some time.  This
      format is just like version 0, but it supports extensions.
      Implementations must reject extensions that they don't support.
      
      Add support for this format version and reject any extensions but
      extensions.noop, which is the only extension we currently support.
      
      While we're at it, also clean up an error message.
      brian m. carlson committed
  16. 07 Feb, 2020 6 commits
    • tests: diff: add test to verify behaviour with empty dir ordering · 17670ef2
      It was reported that, given a file "abc.txt", a diff will be shown if an
      empty directory "abb/" is created, but not if "abd/" is created. Add a
      test to verify that we do the right thing here and do not depend on any
      ordering.
      Patrick Steinhardt committed
    • tests: diff: verify that we are able to diff with empty subtrees · b0691db3
      While it is not allowed for a tree to have an empty tree as child (e.g.
      an empty directory), libgit2's tree builder makes it easy to create such
      trees. As a result, some applications may inadvertently end up with such
      an invalid tree, and we should try our best and handle them.
      
      One such case is when diffing two trees, where one of both trees has
      such an empty subtree. It was reported that this will cause our diff
      code to fail. While I wasn't able to reproduce this error, let's still
      add a test that verifies we continue to handle them correctly.
      Patrick Steinhardt committed
    • tests: iterator: fix iterator expecting too few items · 26b71d60
      The testcase iterator::workdir::filesystem_gunk sets up quite a lot of
      directories, which is why it only runs in case GITTEST_INVASIVE_SPEED is
      set in the environment. Because we do not run our default CI with this
      variable, we didn't notice commit 852c83ee (refs: refuse to delete
      HEAD, 2020-01-15) breaking the test as it introduced a new reference to
      the "testrepo" repository.
      
      Fix the oversight by increasing the number of expected iterator items.
      Patrick Steinhardt committed
    • tests: add missing error checks · 2e6cbff8
      We should always verify error codes returned by function calls in our
      test suite to not accidentally miss any weird results. Coverity reported
      missing checks in several locations, which this commit fixes.
      Patrick Steinhardt committed
    • tests: blame: fix conversion specifiers in format string · 7d65d4cb
      While the blame helper function `hunk_message` accepts a printf-style
      format string, we didn't add a compiler attribute to let the compiler
      check for correct conversion specifiers. As a result, some users of the
      function used wrong specifiers.
      
      Add the GIT_FORMAT_PRINTF attribute to the function and fix resulting
      warnings by using the correct specifiers.
      Patrick Steinhardt committed
    • transports: http: fix custom headers not being applied · 46228d86
      In commit b9c5b15a (http: use the new httpclient, 2019-12-22), the HTTP
      code got refactored to extract a generic HTTP client that operates
      independently of the Git protocol. Part of refactoring was the creation
      of a new `git_http_request` struct that encapsulates the generation of
      requests. Our Git-specific HTTP transport was converted to use that in
      `generate_request`, but during the process we forgot to set up custom
      headers for the `git_http_request` and as a result we do not send out
      these headers anymore.
      
      Fix the issue by correctly setting up the request's custom headers and
      add a test to verify we correctly send them.
      Patrick Steinhardt committed
  17. 31 Jan, 2020 1 commit
    • fetchhead: strip credentials from remote URL · 93a9044f
      If fetching from an anonymous remote via its URL, then the URL gets
      written into the FETCH_HEAD reference. This is mainly done to give
      valuable context to some commands, like for example git-merge(1), which
      will put the URL into the generated MERGE_MSG. As a result, what gets
      written into FETCH_HEAD may become public in some cases. This is
      especially important considering that URLs may contain credentials, e.g.
      when cloning 'https://foo:bar@example.com/repo' we persist the complete
      URL into FETCH_HEAD and put it without any kind of sanitization into the
      MERGE_MSG. This is obviously bad, as your login data has now just leaked
      as soon as you do git-push(1).
      
      When writing the URL into FETCH_HEAD, upstream git does strip
      credentials first. Let's do the same by trying to parse the remote URL
      as a "real" URL, removing any credentials and then re-formatting the
      URL. In case this fails, e.g. when it's a file path or not a valid URL,
      we just fall back to using the URL as-is without any sanitization. Add
      tests to verify our behaviour.
      Patrick Steinhardt committed
  18. 26 Jan, 2020 1 commit
    • credential: change git_cred to git_credential · 3f54ba8b
      We avoid abbreviations where possible; rename git_cred to
      git_credential.
      
      In addition, we have standardized on a trailing `_t` for enum types,
      instead of using "type" in the name.  So `git_credtype_t` has become
      `git_credential_t` and its members have become `GIT_CREDENTIAL` instead
      of `GIT_CREDTYPE`.
      
      Finally, the source and header files have been renamed to `credential`
      instead of `cred`.
      
      Keep previous name and values as deprecated, and include the new header
      files from the previous ones.
      Edward Thomson committed
  19. 24 Jan, 2020 7 commits
  20. 18 Jan, 2020 1 commit
  21. 16 Jan, 2020 1 commit
  22. 15 Jan, 2020 1 commit
    • refs: refuse to delete HEAD · 852c83ee
      This requires adding a new symbolic ref to the testrepo fixture.
      Some of the existing tests attempt to delete HEAD, expecting a different failure. Introduce and use a non-HEAD symbolic ref instead.
      Adjust a few other tests as needed.
      
      Fixes #5357
      Josh Bleecher Snyder 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. 09 Jan, 2020 1 commit