1. 10 Jun, 2017 1 commit
    • smart_protocol: fix parsing of server ACK responses · e141f079
      Fix ACK parsing in wait_while_ack() internal function. This patch
      handles the case where multi_ack_detailed mode sends 'ready' ACKs. The
      existing functionality would bail out too early, thus causing the
      processing of the ensuing packfile to fail if/when 'ready' ACKs were
      sent.
      Roger Gee committed
  2. 10 Feb, 2017 1 commit
  3. 06 Jan, 2017 1 commit
    • smart_pkt: treat empty packet lines as error · 2fdef641
      The Git protocol does not specify what should happen in the case
      of an empty packet line (that is a packet line "0004"). We
      currently indicate success, but do not return a packet in the
      case where we hit an empty line. The smart protocol was not
      prepared to handle such packets in all cases, though, resulting
      in a `NULL` pointer dereference.
      
      Fix the issue by returning an error instead. As such kind of
      packets is not even specified by upstream, this is the right
      thing to do.
      Patrick Steinhardt committed
  4. 29 Dec, 2016 1 commit
  5. 12 Dec, 2016 2 commits
  6. 02 Nov, 2016 2 commits
    • transports: smart: abort receiving packets on end of stream · 62494bf2
      When trying to receive packets from the remote, we loop until
      either an error distinct to `GIT_EBUFS` occurs or until we
      successfully parsed the packet. This does not honor the case
      where we are looping over an already closed socket which has no
      more data, leaving us in an infinite loop if we got a bogus
      packet size or if the remote hang up.
      
      Fix the issue by returning `GIT_EEOF` when we cannot read data
      from the socket anymore.
      Patrick Steinhardt committed
    • transports: smart: abort ref announcement on early end of stream · 61530c49
      When reading a server's reference announcements via the smart
      protocol, we expect the server to send multiple flushes before
      the protocol is finished. If we fail to receive new data from the
      socket, we will only return an end of stream error if we have not
      seen any flush yet.
      
      This logic is flawed in that we may run into an infinite loop
      when receiving a server's reference announcement with a bogus
      flush packet. E.g. assume the last flushing package is changed to
      not be '0000' but instead any other value. In this case, we will
      still await one more flush package and ignore the fact that we
      are not receiving any data from the socket, causing an infinite
      loop.
      
      Fix the issue by always returning `GIT_EEOF` if the socket
      indicates an end of stream.
      Patrick Steinhardt committed
  7. 07 Jun, 2016 1 commit
    • transports: smart: fix potential invalid memory dereferences · 7d02019a
      When we receive a packet of exactly four bytes encoding its
      length as those four bytes it can be treated as an empty line.
      While it is not really specified how those empty lines should be
      treated, we currently ignore them and do not return an error when
      trying to parse it but simply advance the data pointer.
      
      Callers invoking `git_pkt_parse_line` are currently not prepared
      to handle this case as they do not explicitly check this case.
      While they could always reset the passed out-pointer to `NULL`
      before calling `git_pkt_parse_line` and determine if the pointer
      has been set afterwards, it makes more sense to update
      `git_pkt_parse_line` to set the out-pointer to `NULL` itself when
      it encounters such an empty packet. Like this it is guaranteed
      that there will be no invalid memory references to free'd
      pointers.
      
      As such, the issue has been fixed such that `git_pkt_parse_line`
      always sets the packet out pointer to `NULL` when an empty packet
      has been received and callers check for this condition, skipping
      such packets.
      Patrick Steinhardt committed
  8. 08 Mar, 2016 1 commit
  9. 18 Feb, 2016 1 commit
  10. 12 Jan, 2016 1 commit
  11. 14 Aug, 2015 1 commit
  12. 20 May, 2015 1 commit
  13. 14 May, 2015 1 commit
  14. 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
  15. 13 Feb, 2015 1 commit
  16. 29 Dec, 2014 1 commit
  17. 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
  18. 16 Sep, 2014 1 commit
  19. 02 Sep, 2014 1 commit
  20. 27 Jun, 2014 1 commit
  21. 22 May, 2014 1 commit
  22. 21 May, 2014 1 commit
    • smart: store reported symrefs · 8156835d
      The protocol has a capability which allows the server to tell us which
      refs are symrefs, so we can e.g. know which is the default branch.
      
      This capability is different from the ones we already support, as it's
      not setting a flag to true, but requires us to store a list of
      refspec-formatted mappings.
      
      This commit does not yet expose the information in the reference
      listing.
      Carlos Martín Nieto committed
  23. 21 Apr, 2014 3 commits
  24. 20 Apr, 2014 1 commit
  25. 25 Feb, 2014 1 commit
  26. 11 Dec, 2013 1 commit
    • 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
  27. 03 Dec, 2013 1 commit
  28. 18 Nov, 2013 1 commit
  29. 11 Nov, 2013 2 commits
  30. 05 Nov, 2013 1 commit
  31. 01 Nov, 2013 2 commits
  32. 30 Oct, 2013 2 commits
    • protocol: basic support for multi_ack_detailed · 2f8c481c
      This tells the server that we speak it, but we don't make use of its
      extra information to determine if there's a better place to stop
      negotiating.
      
      In a somewhat-related change, reorder the capabilities so we ask for
      them in the same order as git does.
      
      Also take this opportunity to factor out a fairly-indented portion of
      the negotiation logic.
      Carlos Martín Nieto committed
    • indexer: remove the stream infix · a6154f21
      It was there to keep it apart from the one which read in from a file on
      disk. This other indexer does not exist anymore, so there is no need for
      anything other than git_indexer to refer to it.
      
      While here, rename _add() function to _append() and _finalize() to
      _commit(). The former change is cosmetic, while the latter avoids
      talking about "finalizing", which OO languages use to mean something
      completely different.
      Carlos Martín Nieto committed