1. 20 Jan, 2015 1 commit
  2. 21 Nov, 2014 1 commit
  3. 01 Oct, 2014 1 commit
  4. 15 Aug, 2014 1 commit
  5. 23 Jun, 2014 1 commit
    • crlf: pass-through mixed EOL buffers from LF->CRLF · 5a76ad35
      When checking out files, we're performing conversion into the user's
      native line endings, but we only want to do it for files which have
      consistent line endings. Refuse to perform the conversion for mixed-EOL
      files.
      
      The CRLF->LF filter is left as-is, as that conversion is considered to be
      normalization by git and should force a conversion of the line endings.
      Carlos Martín Nieto committed
  6. 23 Apr, 2014 1 commit
  7. 01 Apr, 2014 1 commit
  8. 20 Jan, 2014 1 commit
  9. 14 Nov, 2013 1 commit
  10. 17 Sep, 2013 1 commit
    • Start of filter API + git_blob_filtered_content · 0cf77103
      This begins the process of exposing git_filter objects to the
      public API.  This includes:
      
      * new public type and API for `git_buffer` through which an
        allocated buffer can be passed to the user
      * new API `git_blob_filtered_content`
      * make the git_filter type and GIT_FILTER_TO_... constants public
      Russell Belfer committed
  11. 19 Aug, 2013 1 commit
    • Skip UTF-8 BOM in binary detection · c0b01b75
      When a git_buf contains a UTF-8 BOM, the three bytes comprising
      that BOM are treated as unprintable characters.  For a small git_buf,
      the three BOM characters overwhelm the printable characters.  This
      is problematic when trying to check out a small file as the CR/LF
      filtering will not apply.
      Edward Thomson committed
  12. 31 Jul, 2013 1 commit
    • Major rename detection changes · d730d3f4
      After doing further profiling, I found that a lot of time was
      being spent attempting to insert hashes into the file hash
      signature when using the rolling hash because the rolling hash
      approach generates a hash per byte of the file instead of one
      per run/line of data.
      
      To optimize this, I decided to convert back to a run-based file
      signature algorithm which would be more like core Git.
      
      After changing this, a number of the existing tests started to
      fail.  In some cases, this appears to have been because the test
      was coded to be too specific to the particular results of the file
      similarity metric and in some cases there appear to have been bugs
      in the core rename detection code where only by the coincidence
      of the file similarity scoring were the expected results being
      generated.
      
      This renames all the variables in the core rename detection code
      to be more consistent and hopefully easier to follow which made it
      a bit easier to reason about the behavior of that code and fix the
      problems that I was seeing.  I think it's in better shape now.
      
      There are a couple of tests now that attempt to stress test the
      rename detection code and they are quite slow.  Most of the time
      is spent setting up the test data on disk and in the index.  When
      we roll out performance improvements for index insertion, it
      should also speed up these tests I hope.
      Russell Belfer committed
  13. 25 Mar, 2013 1 commit
    • Move crlf conversion into buf_text · 3658e81e
      This adds crlf/lf conversion functions into buf_text with more
      efficient implementations that bypass the high level buffer
      functions.  They attempt to minimize the number of reallocations
      done and they directly write the buffer data as needed if they
      know that there is enough memory allocated to memcpy data.
      
      Tests are added for these new functions.  The crlf.c code is
      updated to use the new functions.
      
      Removed the include of buf_text.h from filter.h and just include
      it more narrowly in the places that need it.
      Russell Belfer committed
  14. 20 Feb, 2013 4 commits
  15. 29 Jan, 2013 1 commit
  16. 11 Jan, 2013 1 commit
    • Match binary file check of core git in diff · 0d65acad
      Core git just looks for NUL bytes in files when deciding about
      is-binary inside diff (although it uses a better algorithm in
      checkout, when deciding if CRLF conversion should be done).
      Libgit2 was using the better algorithm in both places, but that
      is causing some confusion.  For now, this makes diff just look
      for NUL bytes to decide if a file is binary by content in diff.
      Russell Belfer committed
  17. 28 Nov, 2012 1 commit
    • Consolidate text buffer functions · 7bf87ab6
      There are many scattered functions that look into the contents of
      buffers to do various text manipulations (such as escaping or
      unescaping data, calculating text stats, guessing if content is
      binary, etc).  This groups all those functions together into a
      new file and converts the code to use that.
      
      This has two enhancements to existing functionality.  The old
      text stats function is significantly rewritten and the BOM
      detection code was extended (although largely we can't deal with
      anything other than a UTF8 BOM).
      Russell Belfer committed
  18. 10 Oct, 2012 1 commit
  19. 23 Aug, 2012 1 commit
  20. 24 Jul, 2012 1 commit
  21. 12 Jul, 2012 1 commit
  22. 11 Jul, 2012 1 commit
  23. 15 May, 2012 1 commit
    • Ranged iterators and rewritten git_status_file · 41a82592
      The goal of this work is to rewrite git_status_file to use the
      same underlying code as git_status_foreach.
      
      This is done in 3 phases:
      
      1. Extend iterators to allow ranged iteration with start and
         end prefixes for the range of file names to be covered.
      2. Improve diff so that when there is a pathspec and there is
         a common non-wildcard prefix of the pathspec, it will use
         ranged iterators to minimize excess iteration.
      3. Rewrite git_status_file to call git_status_foreach_ext
         with a pathspec that covers just the one file being checked.
      
      Since ranged iterators underlie the status & diff implementation,
      this is actually fairly efficient.  The workdir iterator does
      end up loading the contents of all the directories down to the
      single file, which should ideally be avoided, but it is pretty
      good.
      Russell Belfer committed
  24. 17 Apr, 2012 1 commit
  25. 21 Mar, 2012 1 commit
  26. 27 Feb, 2012 1 commit
    • buffer: Unify `git_fbuffer` and `git_buf` · 13224ea4
      This makes so much sense that I can't believe it hasn't been done
      before. Kill the old `git_fbuffer` and read files straight into
      `git_buf` objects.
      
      Also: In order to fully support 4GB files in 32-bit systems, the
      `git_buf` implementation has been changed from using `ssize_t` for
      storage and storing negative values on allocation failure, to using
      `size_t` and changing the buffer pointer to a magical pointer on
      allocation failure.
      
      Hopefully this won't break anything.
      Vicent Martí committed
  27. 25 Jan, 2012 1 commit
  28. 08 Dec, 2011 1 commit
    • Use git_buf for path storage instead of stack-based buffers · 97769280
      This converts virtually all of the places that allocate GIT_PATH_MAX
      buffers on the stack for manipulating paths to use git_buf objects
      instead.  The patch is pretty careful not to touch the public API
      for libgit2, so there are a few places that still use GIT_PATH_MAX.
      
      This extends and changes some details of the git_buf implementation
      to add a couple of extra functions and to make error handling easier.
      
      This includes serious alterations to all the path.c functions, and
      several of the fileops.c ones, too.  Also, there are a number of new
      functions that parallel existing ones except that use a git_buf
      instead of a stack-based buffer (such as git_config_find_global_r
      that exists alongsize git_config_find_global).
      
      This also modifies the win32 version of p_realpath to allocate whatever
      buffer size is needed to accommodate the realpath instead of hardcoding
      a GIT_PATH_MAX limit, but that change needs to be tested still.
      Russell Belfer committed
  29. 30 Nov, 2011 4 commits
  30. 28 Nov, 2011 3 commits