1. 05 Mar, 2019 1 commit
    • Jeff King's avatar
      fetch: avoid calling write_or_die() · 37c80012
      Jeff King authored
      The write_or_die() function has one quirk that a caller might not
      expect: when it sees EPIPE from the write() call, it translates that
      into a death by SIGPIPE. This doesn't change the overall behavior (the
      program exits either way), but it does potentially confuse test scripts
      looking for a non-signal exit code.
      Let's switch away from using write_or_die() in a few code paths, which
      will give us more consistent exit codes. It also gives us the
      opportunity to write more descriptive error messages, since we have
      context that write_or_die() does not.
      Note that this won't do much by itself, since we'd typically be killed
      by SIGPIPE before write_or_die() even gets a chance to do its thing.
      That will be addressed in the next patch.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  2. 03 Mar, 2019 1 commit
    • Jonathan Tan's avatar
      remote-curl: use post_rpc() for protocol v2 also · a97d0079
      Jonathan Tan authored
      When transmitting and receiving POSTs for protocol v0 and v1,
      remote-curl uses post_rpc() (and associated functions), but when doing
      the same for protocol v2, it uses a separate set of functions
      (proxy_rpc() and others). Besides duplication of code, this has caused
      at least one bug: the auth retry mechanism that was implemented in v0/v1
      was not implemented in v2.
      To fix this issue and avoid it in the future, make remote-curl also use
      post_rpc() when handling protocol v2. Because line lengths are written
      to the HTTP request in protocol v2 (unlike in protocol v0/v1), this
      necessitates changes in post_rpc() and some of the functions it uses;
      perform these changes too.
      A test has been included to ensure that the code for both the unchunked
      and chunked variants of the HTTP request is exercised.
      Note: stateless_connect() has been updated to use the lower-level packet
      reading functions instead of struct packet_reader. The low-level control
      is necessary here because we cannot change the destination buffer of
      struct packet_reader while it is being used; struct packet_buffer has a
      peeking mechanism which relies on the destination buffer being present
      in between a peek and a read.
      Signed-off-by: default avatarJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  3. 17 Jan, 2019 2 commits
    • Jonathan Tan's avatar
      {fetch,upload}-pack: sideband v2 fetch response · 0bbc0bc5
      Jonathan Tan authored
      Currently, a response to a fetch request has sideband support only while
      the packfile is being sent, meaning that the server cannot send notices
      until the start of the packfile.
      Extend sideband support in protocol v2 fetch responses to the whole
      response. upload-pack will advertise it if the
      uploadpack.allowsidebandall configuration variable is set, and
      fetch-pack will automatically request it if advertised.
      If the sideband is to be used throughout the whole response, upload-pack
      will use it to send errors instead of prefixing a PKT-LINE payload with
      "ERR ".
      This will be tested in a subsequent patch.
      Signed-off-by: default avatarJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jonathan Tan's avatar
      sideband: reverse its dependency on pkt-line · fbd76cd4
      Jonathan Tan authored
      A subsequent patch will teach struct packet_reader a new field that, if
      set, instructs it to interpret read data as multiplexed. This will
      create a dependency from pkt-line to sideband.
      To avoid a circular dependency, split recv_sideband() into 2 parts: the
      reading loop (left in recv_sideband()) and the processing of the
      contents (in demultiplex_sideband()), and move the former into pkt-line.
      This reverses the direction of dependency: sideband no longer depends on
      pkt-line, and pkt-line now depends on sideband.
      Signed-off-by: default avatarJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  4. 15 Jan, 2019 1 commit
    • Jonathan Tan's avatar
      pkt-line: introduce struct packet_writer · bc2e795c
      Jonathan Tan authored
      A future patch will allow the client to request multiplexing of the
      entire fetch response (and not only during packfile transmission), which
      in turn allows the server to send progress and keepalive messages at any
      time during the response.
      It will be convenient for a future patch if writing options
      (specifically, whether the written data is to be multiplexed) could be
      controlled from a single place, so create struct packet_writer to serve
      as that place, and modify upload-pack to use it.
      Currently, it only stores the output fd, but a subsequent patch will (as
      described above) introduce an option to determine if the written data is
      to be multiplexed.
      Signed-off-by: default avatarJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  5. 02 Jan, 2019 1 commit
    • Masaya Suzuki's avatar
      pack-protocol.txt: accept error packets in any context · 2d103c31
      Masaya Suzuki authored
      In the Git pack protocol definition, an error packet may appear only in
      a certain context. However, servers can face a runtime error (e.g. I/O
      error) at an arbitrary timing. This patch changes the protocol to allow
      an error packet to be sent instead of any packet.
      Without this protocol spec change, when a server cannot process a
      request, there's no way to tell that to a client. Since the server
      cannot produce a valid response, it would be forced to cut a connection
      without telling why. With this protocol spec change, the server can be
      more gentle in this situation. An old client may see these error packets
      as an unexpected packet, but this is not worse than having an unexpected
      Following this protocol spec change, the error packet handling code is
      moved to pkt-line.c. Implementation wise, this implementation uses
      pkt-line to communicate with a subprocess. Since this is not a part of
      Git protocol, it's possible that a packet that is not supposed to be an
      error packet is mistakenly parsed as an error packet. This error packet
      handling is enabled only for the Git pack protocol parsing code
      considering this.
      Signed-off-by: default avatarMasaya Suzuki <masayasuzuki@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  6. 23 Jul, 2018 2 commits
  7. 06 May, 2018 1 commit
    • Johannes Schindelin's avatar
      Replace all die("BUG: ...") calls by BUG() ones · 033abf97
      Johannes Schindelin authored
      In d8193743 (usage.c: add BUG() function, 2017-05-12), a new macro
      was introduced to use for reporting bugs instead of die(). It was then
      subsequently used to convert one single caller in 588a538a
      (setup_git_env: convert die("BUG") to BUG(), 2017-05-12).
      The cover letter of the patch series containing this patch
      (cf 20170513032414.mfrwabt4hovujde2@sigill.intra.peff.net) is not
      terribly clear why only one call site was converted, or what the plan
      is for other, similar calls to die() to report bugs.
      Let's just convert all remaining ones in one fell swoop.
      This trick was performed by this invocation:
      	sed -i 's/die("BUG: /BUG("/g' $(git grep -l 'die("BUG' \*.c)
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  8. 15 Mar, 2018 1 commit
  9. 14 Mar, 2018 3 commits
    • Brandon Williams's avatar
      pkt-line: add delim packet support · a4cfd41c
      Brandon Williams authored
      One of the design goals of protocol-v2 is to improve the semantics of
      flush packets.  Currently in protocol-v1, flush packets are used both to
      indicate a break in a list of packet lines as well as an indication that
      one side has finished speaking.  This makes it particularly difficult
      to implement proxies as a proxy would need to completely understand git
      protocol instead of simply looking for a flush packet.
      To do this, introduce the special deliminator packet '0001'.  A delim
      packet can then be used as a deliminator between lists of packet lines
      while flush packets can be reserved to indicate the end of a response.
      Documentation for how this packet will be used in protocol v2 will
      included in a future patch.
      Signed-off-by: default avatarBrandon Williams <bmwill@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Brandon Williams's avatar
      pkt-line: allow peeking a packet line without consuming it · 77dabc14
      Brandon Williams authored
      Sometimes it is advantageous to be able to peek the next packet line
      without consuming it (e.g. to be able to determine the protocol version
      a server is speaking).  In order to do that introduce 'struct
      packet_reader' which is an abstraction around the normal packet reading
      logic.  This enables a caller to be able to peek a single line at a time
      using 'packet_reader_peek()' and having a caller consume a line by
      calling 'packet_reader_read()'.
      Signed-off-by: default avatarBrandon Williams <bmwill@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Brandon Williams's avatar
      pkt-line: introduce packet_read_with_status · 2153d478
      Brandon Williams authored
      The current pkt-line API encodes the status of a pkt-line read in the
      length of the read content.  An error is indicated with '-1', a flush
      with '0' (which can be confusing since a return value of '0' can also
      indicate an empty pkt-line), and a positive integer for the length of
      the read content otherwise.  This doesn't leave much room for allowing
      the addition of additional special packets in the future.
      To solve this introduce 'packet_read_with_status()' which reads a packet
      and returns the status of the read encoded as an 'enum packet_status'
      type.  This allows for easily identifying between special and normal
      packets as well as errors.  It also enables easily adding a new special
      packet in the future.
      Signed-off-by: default avatarBrandon Williams <bmwill@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  10. 17 Oct, 2017 1 commit
  11. 27 Sep, 2017 1 commit
    • Jeff King's avatar
      prefer "!=" when checking read_in_full() result · 61d36330
      Jeff King authored
      Comparing the result of read_in_full() using less-than is
      potentially dangerous, as a negative return value may be
      converted to an unsigned type and be considered a success.
      This is discussed further in 561598cfcf (read_pack_header:
      handle signed/unsigned comparison in read result,
      Each of these instances is actually fine in practice:
       - in get-tar-commit-id, the HEADERSIZE macro expands to a
         signed integer. If it were switched to an unsigned type
         (e.g., a size_t), then it would be a bug.
       - the other two callers check for a short read only after
         handling a negative return separately. This is a fine
         practice, but we'd prefer to model "!=" as a general
      So all of these cases can be considered cleanups and not
      actual bugfixes.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  12. 14 Sep, 2017 1 commit
    • Jeff King's avatar
      pkt-line: check write_in_full() errors against "< 0" · 4c95e3dd
      Jeff King authored
      As with the previous two commits, we prefer to check
      write_in_full()'s return value to see if it is negative,
      rather than comparing it to the input length.
      These cases actually flip the logic to check for success,
      making conversion a little different than in other cases. We
      could of course write:
        if (write_in_full(...) >= 0)
                return 0;
        return error(...);
      But our usual method of spelling write() error checks is
      just "< 0". So let's flip the logic for each of these
      conditionals to our usual style.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  13. 06 Sep, 2017 1 commit
  14. 26 Jul, 2017 1 commit
    • Jonathan Tan's avatar
      sub-process: refactor handshake to common function · fa64a2fd
      Jonathan Tan authored
      Refactor, into a common function, the version and capability negotiation
      done when invoking a long-running process as a clean or smudge filter.
      This will be useful for other Git code that needs to interact similarly
      with a long-running process.
      As you can see in the change to t0021, this commit changes the error
      message reported when the long-running process does not introduce itself
      with the expected "server"-terminated line. Originally, the error
      message reports that the filter "does not support filter protocol
      version 2", differentiating between the old single-file filter protocol
      and the new multi-file filter protocol - I have updated it to something
      more generic and useful.
      Signed-off-by: default avatarJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  15. 08 May, 2017 3 commits
  16. 17 Oct, 2016 6 commits
  17. 07 Sep, 2016 1 commit
  18. 01 Sep, 2015 1 commit
    • Jeff King's avatar
      pkt-line: show packets in async processes as "sideband" · fd89433d
      Jeff King authored
      If you run "GIT_TRACE_PACKET=1 git push", you may get
      confusing output like (line prefixes omitted for clarity):
         packet:      push< \1000eunpack ok0019ok refs/heads/master0000
         packet:      push< unpack ok
         packet:      push< ok refs/heads/master
         packet:      push< 0000
         packet:      push< 0000
      Why do we see the data twice, once apparently wrapped inside
      another pkt-line, and once unwrapped? Why do we get two
      flush packets?
      The answer is that we start an async process to demux the
      sideband data. The first entry comes from the sideband
      process reading the data, and the second from push itself.
      Likewise, the first flush is inside the demuxed packet, and
      the second is an actual sideband flush.
      We can make this a bit more clear by marking the sideband
      demuxer explicitly as "sideband" rather than "push". The
      most elegant way to do this would be to simply call
      packet_trace_identity() inside the sideband demuxer. But we
      can't do that reliably, because it relies on a global
      variable, which might be shared if pthreads are in use.
      What we really need is thread-local storage for
      packet_trace_identity. But the async code does not provide
      an interface for that, and it would be messy to add it here
      (we'd have to care about pthreads, initializing our
      pthread_key_t ahead of time, etc).
      So instead, let us just assume that any async process is
      handling sideband data. That's always true now, and is
      likely to remain so in the future.
      The output looks like:
         packet:  sideband< \1000eunpack ok0019ok refs/heads/master0000
         packet:      push< unpack ok
         packet:      push< ok refs/heads/master
         packet:      push< 0000
         packet:  sideband< 0000
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  19. 16 Jun, 2015 1 commit
    • Jeff King's avatar
      pkt-line: support tracing verbatim pack contents · 32359838
      Jeff King authored
      When debugging the pack protocol, it is sometimes useful to
      store the verbatim pack that we sent or received on the
      wire. Looking at the on-disk result is often not helpful for
      a few reasons:
        1. If the operation is a clone, we destroy the repo on
           failure, leaving nothing on disk.
        2. If the pack is small, we unpack it immediately, and the
           full pack never hits the disk.
        3. If we feed the pack to "index-pack --fix-thin", the
           resulting pack has the extra delta bases added to it.
      We already have a GIT_TRACE_PACKET mechanism for tracing
      packets. Let's extend it with GIT_TRACE_PACKFILE to dump the
      verbatim packfile.
      There are a few other positive fallouts that come from
      rearranging this code:
       - We currently disable the packet trace after seeing the
         PACK header, even though we may get human-readable lines
         on other sidebands; now we include them in the trace.
       - We currently try to print "PACK ..." in the trace to
         indicate that the packfile has started. But because we
         disable packet tracing, we never printed this line. We
         will now do so.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  20. 15 Jun, 2015 2 commits
    • Jeff King's avatar
      pkt-line: tighten sideband PACK check when tracing · d6d1a75e
      Jeff King authored
      To find the start of the pack data, we accept the word PACK
      at the beginning of any sideband channel, even though what
      we really want is to find the pack data on channel 1. In
      practice this doesn't matter, as sideband-2 messages tend to
      start with "error:" or similar, but it is a good idea to be
      explicit (especially as we add more code in this area, we
      will rely on this assumption).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      pkt-line: simplify starts_with checks in packet tracing · f3612acb
      Jeff King authored
      We carefully check that our pkt buffer has enough characters
      before seeing if it starts with "PACK". The intent is to
      avoid reading random memory if we get a short buffer like
      However, we know that the traced packets are always
      NUL-terminated. They come from one of these sources:
        1. A string literal.
        2. `format_packet`, which uses a strbuf.
        3. `packet_read`, which defensively NUL-terminates what we
      We can therefore drop the length checks, as we know we will
      hit the trailing NUL if we have a short input.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  21. 10 Dec, 2014 1 commit
    • Jeff King's avatar
      pkt-line: allow writing of LARGE_PACKET_MAX buffers · 8e9faf27
      Jeff King authored
      When we send out pkt-lines with refnames, we use a static
      1000-byte buffer. This means that the maximum size of a ref
      over the git protocol is around 950 bytes (the exact size
      depends on the protocol line being written, but figure on a sha1
      plus some boilerplate).
      This is enough for any sane workflow, but occasionally odd
      things happen (e.g., a bug may create a ref "foo/foo/foo/..."
      accidentally).  With the current code, you cannot even use
      "push" to delete such a ref from a remote.
      Let's switch to using a strbuf, with a hard-limit of
      LARGE_PACKET_MAX (which is specified by the protocol).  This
      matches the size of the readers, as of 74543a04 (pkt-line:
      provide a LARGE_PACKET_MAX static buffer, 2013-02-20).
      Versions of git older than that will complain about our
      large packets, but it's really no worse than the current
      behavior. Right now the sender barfs with "impossibly long
      line" trying to send the packet, and afterwards the reader
      will barf with "protocol error: bad line length %d", which
      is arguably better anyway.
      Note that we're not really _solving_ the problem here, but
      just bumping the limits. In theory, the length of a ref is
      unbounded, and pkt-line can only represent sizes up to
      65531 bytes. So we are just bumping the limit, not removing
      it.  But hopefully 64K should be enough for anyone.
      As a bonus, by using a strbuf for the formatting we can
      eliminate an unnecessary copy in format_buf_write.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  22. 14 Jul, 2014 1 commit
    • Karsten Blees's avatar
      trace: improve trace performance · 6aa30857
      Karsten Blees authored
      The trace API currently rechecks the environment variable and reopens the
      trace file on every API call. This has the ugly side effect that errors
      (e.g. file cannot be opened, or the user specified a relative path) are
      also reported on every call. Performance can be improved by about factor
      three by remembering the environment state and keeping the file open.
      Replace the 'const char *key' parameter in the API with a pointer to a
      'struct trace_key' that bundles the environment variable name with
      additional, trace-internal state. Change the call sites of these APIs to
      use a static 'struct trace_key' instead of a string constant.
      In trace.c::get_trace_fd(), save and reuse the file descriptor in 'struct
      Add a 'trace_disable()' API, so that packet_trace() can cleanly disable
      tracing when it encounters packed data (instead of using unsetenv()).
      Signed-off-by: default avatarKarsten Blees <blees@dcon.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  23. 05 Dec, 2013 1 commit
    • Christian Couder's avatar
      replace {pre,suf}fixcmp() with {starts,ends}_with() · 59556548
      Christian Couder authored
      Leaving only the function definitions and declarations so that any
      new topic in flight can still make use of the old functions, replace
      existing uses of the prefixcmp() and suffixcmp() with new API
      The change can be recreated by mechanically applying this:
          $ git grep -l -e prefixcmp -e suffixcmp -- \*.c |
            grep -v strbuf\\.c |
            xargs perl -pi -e '
      on the result of preparatory changes in this series.
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  24. 24 Feb, 2013 1 commit
    • Jeff King's avatar
      pkt-line: share buffer/descriptor reading implementation · 4981fe75
      Jeff King authored
      The packet_read function reads from a descriptor. The
      packet_get_line function is similar, but reads from an
      in-memory buffer, and uses a completely separate
      implementation. This patch teaches the generic packet_read
      function to accept either source, and we can do away with
      packet_get_line's implementation.
      There are two other differences to account for between the
      old and new functions. The first is that we used to read
      into a strbuf, but now read into a fixed size buffer. The
      only two callers are fine with that, and in fact it
      simplifies their code, since they can use the same
      static-buffer interface as the rest of the packet_read_line
      callers (and we provide a similar convenience wrapper for
      reading from a buffer rather than a descriptor).
      This is technically an externally-visible behavior change in
      that we used to accept arbitrary sized packets up to 65532
      bytes, and now cap out at LARGE_PACKET_MAX, 65520. In
      practice this doesn't matter, as we use it only for parsing
      smart-http headers (of which there is exactly one defined,
      and it is small and fixed-size). And any extension headers
      would be breaking the protocol to go over LARGE_PACKET_MAX
      The other difference is that packet_get_line would return
      on error rather than dying. However, both callers of
      packet_get_line are actually improved by dying.
      The first caller does its own error checking, but we can
      drop that; as a result, we'll actually get more specific
      reporting about protocol breakage when packet_read dies
      internally. The only downside is that packet_read will not
      print the smart-http URL that failed, but that's not a big
      deal; anybody not debugging can already see the remote's URL
      already, and anybody debugging would want to run with
      GIT_CURL_VERBOSE anyway to see way more information.
      The second caller, which is just trying to skip past any
      extra smart-http headers (of which there are none defined,
      but which we allow to keep room for future expansion), did
      not error check at all. As a result, it would treat an error
      just like a flush packet. The resulting mess would generally
      cause an error later in get_remote_heads, but now we get
      error reporting much closer to the source of the problem.
      Brown-paper-bag-fixes-by: default avatarRamsay Jones <ramsay@ramsay1.demon.co.uk>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  25. 20 Feb, 2013 4 commits
    • Jeff King's avatar
      pkt-line: provide a LARGE_PACKET_MAX static buffer · 74543a04
      Jeff King authored
      Most of the callers of packet_read_line just read into a
      static 1000-byte buffer (callers which handle arbitrary
      binary data already use LARGE_PACKET_MAX). This works fine
      in practice, because:
        1. The only variable-sized data in these lines is a ref
           name, and refs tend to be a lot shorter than 1000
        2. When sending ref lines, git-core always limits itself
           to 1000 byte packets.
      However, the only limit given in the protocol specification
      in Documentation/technical/protocol-common.txt is
      LARGE_PACKET_MAX; the 1000 byte limit is mentioned only in
      pack-protocol.txt, and then only describing what we write,
      not as a specific limit for readers.
      This patch lets us bump the 1000-byte limit to
      LARGE_PACKET_MAX. Even though git-core will never write a
      packet where this makes a difference, there are two good
      reasons to do this:
        1. Other git implementations may have followed
           protocol-common.txt and used a larger maximum size. We
           don't bump into it in practice because it would involve
           very long ref names.
        2. We may want to increase the 1000-byte limit one day.
           Since packets are transferred before any capabilities,
           it's difficult to do this in a backwards-compatible
           way. But if we bump the size of buffer the readers can
           handle, eventually older versions of git will be
           obsolete enough that we can justify bumping the
           writers, as well. We don't have plans to do this
           anytime soon, but there is no reason not to start the
           clock ticking now.
      Just bumping all of the reading bufs to LARGE_PACKET_MAX
      would waste memory. Instead, since most readers just read
      into a temporary buffer anyway, let's provide a single
      static buffer that all callers can use. We can further wrap
      this detail away by having the packet_read_line wrapper just
      use the buffer transparently and return a pointer to the
      static storage.  That covers most of the cases, and the
      remaining ones already read into their own LARGE_PACKET_MAX
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      pkt-line: teach packet_read_line to chomp newlines · 819b929d
      Jeff King authored
      The packets sent during ref negotiation are all terminated
      by newline; even though the code to chomp these newlines is
      short, we end up doing it in a lot of places.
      This patch teaches packet_read_line to auto-chomp the
      trailing newline; this lets us get rid of a lot of inline
      chomping code.
      As a result, some call-sites which are not reading
      line-oriented data (e.g., when reading chunks of packfiles
      alongside sideband) transition away from packet_read_line to
      the generic packet_read interface. This patch converts all
      of the existing callsites.
      Since the function signature of packet_read_line does not
      change (but its behavior does), there is a possibility of
      new callsites being introduced in later commits, silently
      introducing an incompatibility.  However, since a later
      patch in this series will change the signature, such a
      commit would have to be merged directly into this commit,
      not to the tip of the series; we can therefore ignore the
      This is an internal cleanup and should produce no change of
      behavior in the normal case. However, there is one corner
      case to note. Callers of packet_read_line have never been
      able to tell the difference between a flush packet ("0000")
      and an empty packet ("0004"), as both cause packet_read_line
      to return a length of 0. Readers treat them identically,
      even though Documentation/technical/protocol-common.txt says
      we must not; it also says that implementations should not
      send an empty pkt-line.
      By stripping out the newline before the result gets to the
      caller, we will now treat the newline-only packet ("0005\n")
      the same as an empty packet, which in turn gets treated like
      a flush packet. In practice this doesn't matter, as neither
      empty nor newline-only packets are part of git's protocols
      (at least not for the line-oriented bits, and readers who
      are not expecting line-oriented packets will be calling
      packet_read directly, anyway). But even if we do decide to
      care about the distinction later, it is orthogonal to this
      patch.  The right place to tighten would be to stop treating
      empty packets as flush packets, and this change does not
      make doing so any harder.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      pkt-line: provide a generic reading function with options · 03809429
      Jeff King authored
      Originally we had a single function for reading packetized
      data: packet_read_line. Commit 46284dd1 grew a more "gentle"
      form, packet_read, that returns an error instead of dying
      upon reading a truncated input stream. However, it is not
      clear from the names which should be called, or what the
      difference is.
      Let's instead make packet_read be a generic public interface
      that can take option flags, and update the single callsite
      that uses it. This is less code, more clear, and paves the
      way for introducing more options into the generic interface
      later. The function signature is changed, so there should be
      no hidden conflicts with topics in flight.
      While we're at it, we'll document how error conditions are
      handled based on the options, and rename the confusing
      "return_line_fail" option to "gentle_on_eof".  While we are
      cleaning up the names, we can drop the "return_line_fail"
      checks in packet_read_internal entirely.  They look like
        ret = safe_read(..., return_line_fail);
        if (return_line_fail && ret < 0)
      The check for return_line_fail is a no-op; safe_read will
      only ever return an error value if return_line_fail was true
      in the first place.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      pkt-line: drop safe_write function · cdf4fb8e
      Jeff King authored
      This is just write_or_die by another name. The one
      distinction is that write_or_die will treat EPIPE specially
      by suppressing error messages. That's fine, as we die by
      SIGPIPE anyway (and in the off chance that it is disabled,
      write_or_die will simulate it).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>