1. 01 Aug, 2015 2 commits
  2. 12 Jul, 2015 2 commits
  3. 30 Jun, 2015 1 commit
  4. 29 Jun, 2015 1 commit
  5. 26 Jun, 2015 1 commit
  6. 22 Jun, 2015 2 commits
  7. 19 Jun, 2015 1 commit
  8. 02 Jun, 2015 1 commit
  9. 28 May, 2015 5 commits
  10. 21 May, 2015 1 commit
  11. 14 May, 2015 1 commit
  12. 11 May, 2015 1 commit
  13. 21 Apr, 2015 1 commit
    • Fix index-adding functions to know when to trust filemodes. · d3282680
      The idea...sometimes, a filemode is user-specified via an
      explicit git_index_entry.  In this case, believe the user, always.
      
      Sometimes, it is instead built up by statting the file system.  In
      those cases, go with the existing logic we have to determine
      whether the file system supports all filemodes and symlinks, and
      make the best guess.
      
      On file systems which have full filemode and symlink support, this
      commit should make no difference.  On others (most notably Windows),
      this will fix problems things like:
      * git_index_add and git_index_add_frombuffer() should be believed.
      * As a consequence, git_checkout_tree should make the filemodes in
      the index match the ones in the tree.
      * And diffs with GIT_DIFF_UPDATE_INDEX don't write the wrong filemodes.
      * And merges, and probably other downstream stuff now fixed, too.
      
      This makes my previous changes to checkout.c unnecessary,
      so they are now reverted.
      
      Also, added a test for index_entry permissions from git_index_add
      and git_index_add_frombuffer, both of which failed before these changes.
      John Fultz committed
  14. 03 Mar, 2015 2 commits
  15. 25 Feb, 2015 1 commit
  16. 14 Feb, 2015 1 commit
  17. 18 Dec, 2014 3 commits
  18. 17 Dec, 2014 1 commit
  19. 16 Dec, 2014 1 commit
  20. 05 Dec, 2014 1 commit
  21. 27 Oct, 2014 1 commit
  22. 22 Oct, 2014 1 commit
    • tree-cache: correct the entry_count calculation · bb0757d5
      The entry_count field is the amount of index entries covered by a
      particular cache entry, that is how many files are there (recursively)
      under a particular directory.
      
      The current code that attemps to do this is severely defincient and is
      trying to count the amount of children, which always comes up to zero.
      
      We don't even need to recount, since we have the information during the
      cache creation. We can take that number and keep it, as we only ever
      invalidate or replace.
      Carlos Martín Nieto committed
  23. 10 Oct, 2014 3 commits
  24. 03 Aug, 2014 1 commit
  25. 01 Jul, 2014 1 commit
  26. 03 Jun, 2014 1 commit
  27. 22 May, 2014 1 commit
  28. 19 May, 2014 1 commit