1. 04 Dec, 2017 1 commit
  2. 06 Jul, 2016 1 commit
  3. 01 Jul, 2016 1 commit
  4. 16 Jun, 2016 1 commit
  5. 25 Sep, 2015 1 commit
    • Jeff King's avatar
      convert trivial sprintf / strcpy calls to xsnprintf · 5096d490
      Jeff King authored
      We sometimes sprintf into fixed-size buffers when we know
      that the buffer is large enough to fit the input (either
      because it's a constant, or because it's numeric input that
      is bounded in size). Likewise with strcpy of constant
      strings.
      
      However, these sites make it hard to audit sprintf and
      strcpy calls for buffer overflows, as a reader has to
      cross-reference the size of the array with the input. Let's
      use xsnprintf instead, which communicates to a reader that
      we don't expect this to overflow (and catches the mistake in
      case we do).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      5096d490
  6. 02 Jun, 2014 1 commit
    • Michael Naumov's avatar
      sideband.c: do not use ANSI control sequence on non-terminal · 38de156a
      Michael Naumov authored
      Diagnostic messages received on the sideband #2 from the server side
      are sent to the standard error with ANSI terminal control sequence
      "\033[K" that erases to the end of line appended at the end of each
      line.
      
      However, some programs (e.g. GitExtensions for Windows) read and
      interpret and/or show the message without understanding the terminal
      control sequences, resulting them to be shown to their end users.
      To help these programs, squelch the control sequence when the
      standard error stream is not being sent to a tty.
      
      NOTE: I considered to cover the case that a pager has already been
      started. But decided that is probably not worth worrying about here,
      though, as we shouldn't be using a pager for commands that do network
      communications (and if we do, omitting the magic line-clearing signal
      is probably a sane thing to do).
      
      Thanks-to: Erik Faye-Lund <kusmabite@gmail.com>
      Thanks-to: Jeff King <peff@peff.net>
      Signed-off-by: default avatarMichael Naumov <mnaoumov@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      38de156a
  7. 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
      anyway.
      
      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>
      4981fe75
  8. 20 Feb, 2013 2 commits
    • 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
      issue.
      
      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>
      819b929d
    • 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>
      cdf4fb8e
  9. 05 Nov, 2009 1 commit
    • Shawn O. Pearce's avatar
      Smart push over HTTP: client side · de1a2fdd
      Shawn O. Pearce authored
      The git-remote-curl backend detects if the remote server supports
      the git-receive-pack service, and if so, runs git-send-pack in a
      pipe to dump the command and pack data as a single POST request.
      
      The advertisements from the server that were obtained during the
      discovery are passed into git-send-pack before the POST request
      starts.  This permits git-send-pack to operate largely unmodified.
      
      For smaller packs (those under 1 MiB) a HTTP/1.0 POST with a
      Content-Length is used, permitting interaction with any server.
      The 1 MiB limit is arbitrary, but is sufficent to fit most deltas
      created by human authors against text sources with the occasional
      small binary file (e.g. few KiB icon image).  The configuration
      option http.postBuffer can be used to increase (or shink) this
      buffer if the default is not sufficient.
      
      For larger packs which cannot be spooled entirely into the helper's
      memory space (due to http.postBuffer being too small), the POST
      request requires HTTP/1.1 and sets "Transfer-Encoding: chunked".
      This permits the client to upload an unknown amount of data in one
      HTTP transaction without needing to pregenerate the entire pack
      file locally.
      Signed-off-by: default avatarShawn O. Pearce <spearce@spearce.org>
      CC: Daniel Barkalow <barkalow@iabervon.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      de1a2fdd
  10. 11 Mar, 2009 1 commit
    • Johannes Sixt's avatar
      recv_sideband: Bands #2 and #3 always go to stderr · 34df8aba
      Johannes Sixt authored
      This removes the last parameter of recv_sideband, by which the callers
      told which channel bands #2 and #3 should be written to.
      
      Sayeth Shawn Pearce:
      
         The definition of the streams in the current sideband protocol
         are rather well defined for the one protocol that uses it,
         fetch-pack/receive-pack:
      
           stream #1:  pack data
           stream #2:  stderr messages, progress, meant for tty
           stream #3:  abort message, remote is dead, goodbye!
      
      Since both callers of the function passed 2 for the parameter, we hereby
      remove it and send bands #2 and #3 to stderr explicitly using fprintf.
      
      This has the nice side-effect that these two streams pass through our
      ANSI emulation layer on Windows.
      Signed-off-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Acked-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      34df8aba
  11. 03 Sep, 2008 1 commit
    • Nicolas Pitre's avatar
      improve handling of sideband message display · 6b9c42b4
      Nicolas Pitre authored
      Currently the code looks for line break characters in order to prepend
      "remote: " to every line received as many lines can be sent in a single
      chunk.  However the opposite might happen too, i.e. a single message
      line split amongst multiple chunks.  This patch adds support for the
      later case to avoid displays like:
      
      	remote: Compressing objeremote: cts: 100% (313/313), done.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      6b9c42b4
  12. 09 Jan, 2008 1 commit
    • Johannes Sixt's avatar
      recv_sideband: Do not use ANSI escape sequence on dumb terminals. · 13e4760a
      Johannes Sixt authored
      The "clear to end of line" sequence is used to nicely output the progress
      indicator without leaving garbage on the terminal. However, this works
      only on ANSI capable terminals. We use the same check as in color.c to
      find out whether the terminal supports this feature and use a workaround
      (a few spaces in a row) if it does not.
      
      [jc: as an old fashoned git myself, and given the fact that the
      possible prefix and suffix are small number of short constant strings,
      I actually prefer a simpler-and-more-stupid approach.  This is with
      Nico's clean-up.]
      Signed-off-by: default avatarJohannes Sixt <johannes.sixt@telecom.at>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      13e4760a
  13. 05 Nov, 2007 1 commit
  14. 04 Nov, 2007 1 commit
    • Nicolas Pitre's avatar
      fix display overlap between remote and local progress · ebe8fa73
      Nicolas Pitre authored
      It is possible for the remote summary line to be displayed over the
      local progress display line, and therefore that local progress gets
      bumped to the next line.  However, if the progress line is long enough,
      it might not be entirely overwritten by the remote summary line.  This
      creates a messed up display such as:
      
      	remote: Total 310 (delta 160), reused 178 (delta 112)iB/s
      	Receiving objects: 100% (310/310), 379.98 KiB | 136 KiB/s, done.
      
      So we have to clear the screen line before displaying the remote message
      to make sure the local progress is not visible anymore on the first
      line.
      
      Yet some Git versions on the remote side might be sending updates to the
      same line and terminate it with \r, and a separate packet with a single
      \n might be sent later when the progress display is done.  This means
      the screen line must *not* be cleared in that case.
      
      Since the sideband code already has to figure out line breaks in the
      received packet to properly prepend the "remote:" prefix, we can easily
      determine if the remote line about to be displayed is empty.  Only when
      it is not then a proper suffix is inserted before the \r or \n to clear
      the end of the screen line.
      
      Also some magic constants related to the prefix length have been
      replaced with a variable, making it similar to the suffix length
      handling.  Since gcc is smart enough to detect that the variable is
      constant there is no impact on the generated code.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ebe8fa73
  15. 17 Oct, 2007 1 commit
  16. 11 Oct, 2006 1 commit
    • Nicolas Pitre's avatar
      atomic write for sideband remote messages · 9ac13ec9
      Nicolas Pitre authored
      It has been a few times that I ended up with such a confusing display:
      
      |remote: Generating pack...
      |remote: Done counting 17 objects.
      |remote: Result has 9 objects.
      |remote: Deltifying 9 objects.
      |remote:  100% (9/9) done
      |remote: Unpacking 9 objects
      |Total 9, written 9 (delta 8), reused 0 (delta 0)
      | 100% (9/9) done
      
      The confusion can be avoided in most cases by writing the remote message
      in one go to prevent interleacing with local messages.  The buffer
      declaration has been moved inside recv_sideband() to avoid extra string
      copies.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      9ac13ec9
  17. 10 Sep, 2006 2 commits