1. 08 Sep, 2015 1 commit
  2. 28 Jul, 2015 2 commits
  3. 13 May, 2015 2 commits
    • Remove the callbacks struct from the remote · 8f0104ec
      Having the setting be different from calling its actions was not a great
      idea and made for the sake of the wrong convenience.
      
      Instead of that, accept either fetch options, push options or the
      callbacks when dealing with the remote. The fetch options are currently
      only the callbacks, but more options will be moved from setters and
      getters on the remote to the options.
      
      This does mean passing the same struct along the different functions but
      the typical use-case will only call git_remote_fetch() or
      git_remote_push() and so won't notice much difference.
      Carlos Martín Nieto committed
    • push: remove own copy of callbacks · 05259114
      The push object knows which remote it's associated with, and therefore
      does not need to keep its own copy of the callbacks stored in the
      remote.
      
      Remove the copy and simply access the callbacks struct within the
      remote.
      Carlos Martín Nieto committed
  4. 18 Apr, 2015 1 commit
    • push: report the update plan to the caller · efc2fec5
      It can be useful for the caller to know which update commands will be
      sent to the server before the packfile is pushed up. git does this via
      the pre-push hook.
      
      We don't have hooks, but as it adds introspection into what is
      happening, we can add a callback which performs the same function.
      Carlos Martín Nieto committed
  5. 03 Mar, 2015 2 commits
  6. 30 Dec, 2014 1 commit
  7. 09 Nov, 2014 1 commit
    • push: use the common refspec parser · aad638f3
      There is one well-known and well-tested parser which we should use,
      instead of implementing parsing a second time.
      
      The common parser is also augmented to copy the LHS into the RHS if the
      latter is empty.
      
      The expressions test had to change a bit, as we now catch a bad RHS of a
      refspec locally.
      Carlos Martín Nieto committed
  8. 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
  9. 11 Mar, 2013 1 commit
  10. 11 Feb, 2013 1 commit
  11. 08 Jan, 2013 1 commit
  12. 28 Nov, 2012 1 commit