1. 13 Jul, 2011 11 commits
    • tree: More accurate matching on entries · e6629d83
      The old matcher was returning fake matches when given stupid entry
      names. E.g.
      
      	`git2` could be matched by `git2   /`, `git2/foobar`, git2/////`
      	and other stupid stuff
      Vicent Marti committed
    • tree: Fix wrong sort order when querying entries · 761aa2aa
      Fixes #127 (that was quite an outstanding issue).
      
      Rationale:
      
      The tree objects on Git are stored and read following a very specific
      sorting algorithm that places folders before files. That original sort
      was the sort we were storing on memory, but this sort was being queried
      with a binary search that used a simple `strcmp` for comparison, so
      there were many instances where the search was failing.
      
      Obviously, the most straightforward way to fix this is changing the
      binary search CB to use the same comparison method as the sorting CB.
      The problem with this is that the binary search callback compares a path
      and an entry, so there is no way to know if the given path is a folder
      or a standard file.
      
      How do we work around this? Instead of splitting the `entry_byname`
      method in two (one for searching directories and one for searching
      normal files), we just assume that the path we are searching for is of
      the same kind as the path it's being compared at the moment.
      
      	return git_futils_cmp_path(
      		ksearch->filename, ksearch->filename_len, entry->attr & 040000,
              entry->filename, entry->filename_len, entry->attr & 040000);
      
      Since there cannot be a folder and a regular file with the same name on
      the same tree, the most basic equality check will always fail
      for all comparsions, until our path is compared with the actual entry we
      are looking for; in this case, the matching will succeed with the file
      type of the entry -- whatever it was initially.
      
      I hope that makes sense.
      
      PS: While I was at it, I switched the cmp methods to use cached values
      for the length of each filename. That makes searches and sorts
      retardedly fast -- I was wondering the reason of the performance hiccups
      on massive trees; it's because of 2*strlen for each comparsion call.
      Vicent Marti committed
    • index: fix potential overflow · b16692fa
      mode field of git_index_entry_unmerged is array of unsigned ints. It's
      unsafe to cast pointer to an element of the array to long int *. It may
      cause overflow in git_strtol32().
      
      Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
      Kirill A. Shutemov committed
    • index: drop useless type casting · ae9f771c
      Type casting usually points to some trick or bug. It's better not hide
      it between useless type castings.
      
      Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
      Kirill A. Shutemov committed
    • vector: mark internal functions as static · e1fca014
      Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
      Kirill A. Shutemov committed
    • vector: avoid double asserting · 046dfea3
      index_initialize() calls assert() for arguments on its own. No need to
      call it twice.
      
      Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
      Kirill A. Shutemov committed
    • index: drop sort_index() · fad6607a
      Remove dummy wrapper around git_vector_sort().
      
      Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
      Kirill A. Shutemov committed
    • index: do not sort index before git_vector_bsearch2() · 07d34877
      git_vector_bsearch2() calls git_vector_sort(). No need to call it
      directly.
      
      Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
      Kirill A. Shutemov committed
    • index: do not free vectors twice in git_index_free() · 212b379a
      git_index_clear() frees index->entries and index->unmerged. No need to
      free it once again.
      
      Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
      Kirill A. Shutemov committed
  2. 12 Jul, 2011 9 commits
  3. 11 Jul, 2011 8 commits
  4. 10 Jul, 2011 1 commit
  5. 09 Jul, 2011 11 commits