1. 05 Jun, 2020 2 commits
  2. 04 Jun, 2020 1 commit
  3. 03 Jun, 2020 3 commits
  4. 02 Jun, 2020 5 commits
    • offer exact name matching with a `$` suffix · 0d3ce2ac
      When using `-s` to specify a particular test, it will do a prefix match.
      Thus, `-sapply::both::rename_a_to_b_to_c` will match both a test named
      `test_apply_both__rename_a_to_b_to_c` and a test that begins with that
      name, like `test_apply_both__rename_a_to_b_to_c_exact`.
      
      Permit a trailing `$` to `-s` syntax.  This allows a user to specify
      `-sapply::both::rename_a_to_b_to_c$` to match _only_ the
      `test_apply_both__rename_a_to_b_to_c` function.
      
      We already filter to ensure that the given prefix matches the current
      test name.  Also ensure that the length of the test name matches the
      length of the filter, sans trailing `$`.
      Edward Thomson committed
    • clar: remove files internally instead of /bin/rm · ee9e9163
      Similar to how clar has used `/bin/cp` to copy files, it's used
      `/bin/rm` to remove them.  This has similar deficiencies; meaning that
      leaks is noisy and it's slow.  Move it to an internal function.
      Edward Thomson committed
    • clar: copy files internally instead of /bin/cp · 8df4f519
      clar has historically shelled out to `/bin/cp` to copy test fixtures
      into a sandbox.  This has two deficiencies:
      
      1. It's slower than simply opening the source and destination and
         copying them in a read/write loop.  On my Mac, the `/bin/cp` based
         approach takes ~2:40 for a full test pass.  Using a read/write loop
         to copy the files ourselves takes ~1:50.
      
      2. It's noisy.  Since the leak detector follows fork/exec, we'll end up
         running the leak detector on `/bin/cp`.  This would be fine, except
         that the leak detector spams the console on startup and shutdown, so
         it adds a _lot_ of additional information to the test runs that is
         useless.  By not forking and using this internal system, we see much
         less output.
      Edward Thomson committed
  5. 01 Jun, 2020 3 commits
  6. 26 May, 2020 1 commit
  7. 23 May, 2020 3 commits
  8. 16 May, 2020 1 commit
  9. 12 May, 2020 1 commit
  10. 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
  11. 10 May, 2020 3 commits
  12. 14 Apr, 2020 1 commit
  13. 03 Apr, 2020 1 commit
  14. 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
  15. 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
  16. 23 Mar, 2020 1 commit
  17. 10 Mar, 2020 2 commits
  18. 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
  19. 18 Feb, 2020 1 commit
  20. 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
  21. 07 Feb, 2020 4 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