Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Dec 05, 2013

  1. Christian Couder

    replace {pre,suf}fixcmp() with {starts,ends}_with()

    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 <chriscool@tuxfamily.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored November 30, 2013 gitster committed December 05, 2013

Feb 24, 2013

  1. Jeff King

    pkt-line: share buffer/descriptor reading implementation

    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: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored February 23, 2013 gitster committed February 24, 2013

Feb 20, 2013

  1. Jeff King

    pkt-line: provide a LARGE_PACKET_MAX static buffer

    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: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored February 20, 2013 gitster committed February 20, 2013
  2. Jeff King

    pkt-line: teach packet_read_line to chomp newlines

    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: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored February 20, 2013 gitster committed February 20, 2013
  3. Jeff King

    pkt-line: provide a generic reading function with options

    Originally we had a single function for reading packetized
    data: packet_read_line. Commit 46284dd 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: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored February 20, 2013 gitster committed February 20, 2013
  4. Jeff King

    pkt-line: drop safe_write function

    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: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored February 20, 2013 gitster committed February 20, 2013
  5. Jeff King

    pkt-line: move a misplaced comment

    The comment describing the packet writing interface was
    originally written above packet_write, but migrated to be
    above safe_write in f3a3214, 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: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored February 20, 2013 gitster committed February 20, 2013

Jun 19, 2012

  1. remove the impression of unexpectedness when access is denied

    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 <hvoigt@hvoigt.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored June 19, 2012 gitster committed June 19, 2012

Apr 03, 2011

  1. Stephen Boyd

    sparse: Fix errors and silence warnings

     * load_file() returns a void pointer but is using 0 for the return
       value
    
     * builtin/receive-pack.c forgot to include builtin.h
    
     * packet_trace_prefix can be marked static
    
     * ll_merge takes a pointer for its last argument, not an int
    
     * crc32 expects a pointer as the second argument but Z_NULL is defined
       to be 0 (see 38f4d13 sparse fix: Using plain integer as NULL pointer,
       2006-11-18 for more info)
    
    Signed-off-by: Stephen Boyd <bebarino@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored April 03, 2011 gitster committed April 03, 2011

Mar 08, 2011

  1. Jeff King

    add packet tracing debug code

    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: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored February 24, 2011 gitster committed March 08, 2011

Oct 31, 2009

  1. Shawn O. Pearce

    pkt-line: Make packet_read_line easier to debug

    When there is an error parsing the 4 byte length component we now
    display it as part of the die message, this may hint as to what
    data was misunderstood by the application.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored October 30, 2009 gitster committed October 30, 2009
  2. Shawn O. Pearce

    pkt-line: Add strbuf based functions

    These routines help to work with pkt-line values inside of a strbuf,
    permitting simple formatting of buffered network messages.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored October 30, 2009 gitster committed October 30, 2009

Jun 27, 2009

  1. trast

    Convert existing die(..., strerror(errno)) to die_errno()

    Change calls to die(..., strerror(errno)) to use the new die_errno().
    
    In the process, also make slight style adjustments: at least state
    _something_ about the function that failed (instead of just printing
    the pathname), and put paths in single quotes.
    
    Signed-off-by: Thomas Rast <trast@student.ethz.ch>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored June 27, 2009 gitster committed June 27, 2009

May 04, 2008

  1. Heikki Orsila

    Cleanup xread() loops to use read_in_full()

    Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored May 03, 2008 gitster committed May 03, 2008

Jun 07, 2007

  1. Junio C Hamano

    War on whitespace

    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: Junio C Hamano <gitster@pobox.com>
    authored June 07, 2007

May 16, 2007

  1. Johan Herland

    Ensure return value from xread() is always stored into an ssize_t

    This patch fixes all calls to xread() where the return value is not
    stored into an ssize_t. The patch should not have any effect whatsoever,
    other than putting better/more appropriate type names on variables.
    
    Signed-off-by: Johan Herland <johan@herland.net>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored May 15, 2007 Junio C Hamano committed May 15, 2007

Dec 18, 2006

  1. make git a bit less cryptic on fetch errors

    The remote server might not want to tell why it doesn't like us for
    security reasons, but let's make the client report such error in a bit
    less confusing way.  The remote failure remains a mystery, but the local
    message might be a bit less so.
    
    [jc: with a gentle wording updates from Andy Parkins]
    
    Signed-off-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored December 18, 2006 Junio C Hamano committed December 18, 2006

Jun 21, 2006

  1. Merge branch 'ff/c99' into next

    * ff/c99:
      Remove all void-pointer arithmetic.
    authored June 21, 2006
  2. upload-pack/fetch-pack: support side-band communication

    This implements a protocol extension between fetch-pack and
    upload-pack to allow stderr stream from upload-pack (primarily
    used for the progress bar display) to be passed back.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored June 21, 2006

Jun 20, 2006

  1. Remove all void-pointer arithmetic.

    ANSI C99 doesn't allow void-pointer arithmetic. This patch fixes this in
    various ways. Usually the strategy that required the least changes was used.
    
    Signed-off-by: Florian Forster <octo@verplant.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored June 18, 2006 Junio C Hamano committed June 20, 2006

Dec 20, 2005

  1. xread/xwrite: do not worry about EINTR at calling sites.

    We had errno==EINTR check after read(2)/write(2) sprinkled all
    over the places, always doing continue.  Consolidate them into
    xread()/xwrite() wrapper routines.
    
    Credits for suggestion goes to HPA -- bugs are mine.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored December 19, 2005

Jun 30, 2005

  1. Make send/receive-pack be closer to doing something interesting

    authored June 29, 2005
Something went wrong with that request. Please try again.