1. 12 May, 2020 1 commit
  2. 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
  3. 20 Jul, 2019 1 commit
  4. 13 Jun, 2019 1 commit
  5. 10 Jun, 2019 4 commits
  6. 01 Dec, 2018 1 commit
  7. 13 Jul, 2018 1 commit
    • treewide: remove use of C++ style comments · 9994cd3f
      C++ style comment ("//") are not specified by the ISO C90 standard and
      thus do not conform to it. While libgit2 aims to conform to C90, we did
      not enforce it until now, which is why quite a lot of these
      non-conforming comments have snuck into our codebase. Do a tree-wide
      conversion of all C++ style comments to the supported C style comments
      to allow us enforcing strict C90 compliance in a later commit.
      Patrick Steinhardt committed
  8. 10 Jun, 2018 1 commit
  9. 04 Feb, 2018 3 commits
  10. 21 Jan, 2018 1 commit
    • merge: recursive uses larger conflict markers · 185b0d08
      Git uses longer conflict markers in the recursive merge base - two more
      than the default (thus, 9 character long conflict markers).  This allows
      users to tell the difference between the recursive merge conflicts and
      conflicts between the ours and theirs branches.
      
      This was introduced in git d694a17986a28bbc19e2a6c32404ca24572e400f.
      
      Update our tests to expect this as well.
      Edward Thomson committed
  11. 09 Feb, 2017 1 commit
  12. 01 Jan, 2017 1 commit
  13. 26 May, 2016 1 commit
  14. 25 Nov, 2015 11 commits
  15. 22 Oct, 2015 1 commit
  16. 28 Aug, 2015 1 commit
  17. 28 May, 2015 1 commit
    • introduce `git_index_entry_is_conflict` · 9f545b9d
      It's not always obvious the mapping between stage level and
      conflict-ness.  More importantly, this can lead otherwise sane
      people to write constructs like `if (!git_index_entry_stage(entry))`,
      which (while technically correct) is unreadable.
      
      Provide a nice method to help avoid such messy thinking.
      Edward Thomson committed
  18. 11 May, 2015 1 commit
  19. 16 Mar, 2015 3 commits
  20. 01 Oct, 2014 1 commit
  21. 01 Jul, 2014 1 commit
  22. 20 Mar, 2014 2 commits