1. 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
      trace_key'.
      
      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>
      6aa30857
  2. 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
      functions.
      
      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 '
              s|!prefixcmp\(|starts_with\(|g;
              s|prefixcmp\(|!starts_with\(|g;
              s|!suffixcmp\(|ends_with\(|g;
              s|suffixcmp\(|!ends_with\(|g;
            '
      
      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>
      59556548
  3. 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
  4. 20 Feb, 2013 5 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
           characters.
      
        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
      buffers.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      74543a04
    • 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: 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
      this:
      
        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>
      03809429
    • 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
    • Jeff King's avatar
      pkt-line: move a misplaced comment · e1485428
      Jeff King authored
      The comment describing the packet writing interface was
      originally written above packet_write, but migrated to be
      above safe_write in f3a3214e, probably because it is meant to
      generally describe the packet writing interface and not a
      single function. Let's move it into the header file, where
      users of the interface are more likely to see it.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e1485428
  5. 19 Jun, 2012 1 commit
    • Heiko Voigt's avatar
      remove the impression of unexpectedness when access is denied · 46284dd1
      Heiko Voigt authored
      If a server accessed through ssh is denying access git will currently
      issue the message
      
      	"fatal: The remote end hung up unexpectedly"
      
      as the last line. This sounds as if something really ugly just happened.
      Since this is a quite typical situation in which users regularly get
      we do not say that if it happens at the beginning when reading the
      remote heads.
      
      If its in the very first beginning of reading the remote heads it is
      very likely an authentication error or a missing repository.
      
      If it happens later during reading the remote heads we still indicate
      that it happened during this initial contact phase.
      Signed-off-by: Heiko Voigt's avatarHeiko Voigt <hvoigt@hvoigt.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      46284dd1
  6. 03 Apr, 2011 1 commit
  7. 08 Mar, 2011 1 commit
    • Jeff King's avatar
      add packet tracing debug code · bbc30f99
      Jeff King authored
      This shows a trace of all packets coming in or out of a given
      program. This can help with debugging object negotiation or
      other protocol issues.
      
      To keep the code changes simple, we operate at the lowest
      level, meaning we don't necessarily understand what's in the
      packets. The one exception is a packet starting with "PACK",
      which causes us to skip that packet and turn off tracing
      (since the gigantic pack data will not be interesting to
      read, at least not in the trace format).
      
      We show both written and read packets. In the local case,
      this may mean you will see packets twice (written by the
      sender and read by the receiver). However, for cases where
      the other end is remote, this allows you to see the full
      conversation.
      
      Packet tracing can be enabled with GIT_TRACE_PACKET=<foo>,
      where <foo> takes the same arguments as GIT_TRACE.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      bbc30f99
  8. 31 Oct, 2009 2 commits
  9. 27 Jun, 2009 1 commit
  10. 04 May, 2008 1 commit
  11. 07 Jun, 2007 1 commit
    • Junio C Hamano's avatar
      War on whitespace · a6080a0a
      Junio C Hamano authored
      This uses "git-apply --whitespace=strip" to fix whitespace errors that have
      crept in to our source files over time.  There are a few files that need
      to have trailing whitespaces (most notably, test vectors).  The results
      still passes the test, and build result in Documentation/ area is unchanged.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a6080a0a
  12. 16 May, 2007 1 commit
  13. 18 Dec, 2006 1 commit
  14. 21 Jun, 2006 1 commit
  15. 20 Jun, 2006 1 commit
  16. 20 Dec, 2005 1 commit
  17. 30 Jun, 2005 1 commit