1. 13 May, 2015 1 commit
  2. 17 Mar, 2015 1 commit
  3. 11 Mar, 2015 2 commits
    • pack-objects: fill a packbuilder from a walk · 04a36fef
      Most use-cases for the object packer communicate in terms of commits
      which each side has. We already have an object to specify this
      relationship between commits, namely git_revwalk.
      
      By knowing which commits we want to pack and which the other side
      already has, we can perform similar optimisations to git, by marking
      each tree as interesting or uninteresting only once, and not sending
      those trees which we know the other side has.
      Carlos Martín Nieto committed
    • Reorder some khash declarations · b63b76e0
      Keep the definitions in the headers, while putting the declarations in
      the C files. Putting the function definitions in headers causes
      them to be duplicated if you include two headers with them.
      Carlos Martín Nieto committed
  4. 13 Feb, 2015 7 commits
  5. 07 Jun, 2014 1 commit
  6. 08 May, 2014 1 commit
    • Be more careful with user-supplied buffers · 1e4976cb
      This adds in missing calls to `git_buf_sanitize` and fixes a
      number of places where `git_buf` APIs could inadvertently write
      NUL terminator bytes into invalid buffers.  This also changes the
      behavior of `git_buf_sanitize` to NUL terminate a buffer if it can
      and of `git_buf_shorten` to do nothing if it can.
      
      Adds tests of filtering code with zeroed (i.e. unsanitized) buffer
      which was previously triggering a segfault.
      Russell Belfer committed
  7. 07 May, 2014 1 commit
  8. 26 Apr, 2014 1 commit
  9. 21 Apr, 2014 1 commit
  10. 18 Apr, 2014 1 commit
  11. 04 Mar, 2014 1 commit
    • pack-objects: free memory safely · a14aa1e7
      A few fixes have accumulated in this area which have made the freeing of
      data a bit muddy. Make sure to free the data only when needed and once.
      
      When we are going to write a delta to the packfile, we need to free the
      data, otherwise leave it. The current version of the code mixes up the
      checks for po->data and po->delta_data.
      Carlos Martín Nieto committed
  12. 30 Jan, 2014 2 commits
  13. 26 Jan, 2014 1 commit
  14. 14 Jan, 2014 3 commits
  15. 12 Dec, 2013 1 commit
  16. 11 Dec, 2013 4 commits
    • Some callback error check style cleanups · c7b3e1b3
      I find this easier to read...
      Russell Belfer committed
    • Remove converting user error to GIT_EUSER · 25e0b157
      This changes the behavior of callbacks so that the callback error
      code is not converted into GIT_EUSER and instead we propagate the
      return value through to the caller.  Instead of using the
      giterr_capture and giterr_restore functions, we now rely on all
      functions to pass back the return value from a callback.
      
      To avoid having a return value with no error message, the user
      can call the public giterr_set_str or some such function to set
      an error message.  There is a new helper 'giterr_set_callback'
      that functions can invoke after making a callback which ensures
      that some error message was set in case the callback did not set
      one.
      
      In places where the sign of the callback return value is
      meaningful (e.g. positive to skip, negative to abort), only the
      negative values are returned back to the caller, obviously, since
      the other values allow for continuing the loop.
      
      The hardest parts of this were in the checkout code where positive
      return values were overloaded as meaningful values for checkout.
      I fixed this by adding an output parameter to many of the internal
      checkout functions and removing the overload.  This added some
      code, but it is probably a better implementation.
      
      There is some funkiness in the network code where user provided
      callbacks could be returning a positive or a negative value and
      we want to rely on that to cancel the loop.  There are still a
      couple places where an user error might get turned into GIT_EUSER
      there, I think, though none exercised by the tests.
      Russell Belfer committed
    • Further EUSER and error propagation fixes · dab89f9b
      This continues auditing all the places where GIT_EUSER is being
      returned and making sure to clear any existing error using the
      new giterr_user_cancel helper.  As a result, places that relied
      on intercepting GIT_EUSER but having the old error preserved also
      needed to be cleaned up to correctly stash and then retrieve the
      actual error.
      
      Additionally, as I encountered places where error codes were not
      being propagated correctly, I tried to fix them up.  A number of
      those fixes are included in the this commit as well.
      Russell Belfer committed
  17. 12 Nov, 2013 1 commit
  18. 07 Nov, 2013 2 commits
  19. 01 Nov, 2013 1 commit
  20. 30 Oct, 2013 2 commits
  21. 04 Oct, 2013 2 commits
  22. 02 Oct, 2013 1 commit
    • Support cancellation in push operation · 5b188225
      This commit adds cancellation for the push operation. This work consists of:
      
      1) Support cancellation during push operation
          - During object counting phase
          - During network transfer phase
              - Propagate GIT_EUSER error code out to caller
      2) Improve cancellation support during fetch
          - Handle cancellation request during network transfer phase
          - Clear error string when cancelled during indexing
      3) Fix error handling in git_smart__download_pack
      
      Cancellation during push is still only handled in the pack building and
      network transfer stages of push (and not during packbuilding).
      Jameson Miller committed
  23. 30 Sep, 2013 1 commit
    • Initial Implementation of progress reports during push · b176eded
      This adds the basics of progress reporting during push. While progress
      for all aspects of a push operation are not reported with this change,
      it lays the foundation to add these later. Push progress reporting
      can be improved in the future - and consumers of the API should
      just get more accurate information at that point.
      
      The main areas where this is lacking are:
      
      1) packbuilding progress: does not report progress during deltafication,
         as this involves coordinating progress from multiple threads.
      
      2) network progress: reports progress as objects and bytes are going
         to be written to the subtransport (instead of as client gets
         confirmation that they have been received by the server) and leaves
         out some of the bytes that are transfered as part of the push protocol.
         Basically, this reports the pack bytes that are written to the
         subtransport. It does not report the bytes sent on the wire that
         are received by the server. This should be a good estimate of
         progress (and an improvement over no progress).
      Jameson Miller committed
  24. 15 Jul, 2013 1 commit