Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Nov 5, 2009
  1. @spearce @gitster

    Smart push over HTTP: client side

    spearce authored gitster committed
    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: Shawn O. Pearce <spearce@spearce.org>
    CC: Daniel Barkalow <barkalow@iabervon.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Mar 11, 2009
  1. @gitster

    recv_sideband: Bands #2 and #3 always go to stderr

    Johannes Sixt authored gitster committed
    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: Johannes Sixt <j6t@kdbg.org>
    Acked-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Sep 3, 2008
  1. @gitster

    improve handling of sideband message display

    Nicolas Pitre authored gitster committed
    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: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jan 9, 2008
  1. @gitster

    recv_sideband: Do not use ANSI escape sequence on dumb terminals.

    Johannes Sixt authored gitster committed
    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: Johannes Sixt <johannes.sixt@telecom.at>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Nov 5, 2007
  1. @gitster

    sideband.c: ESC is spelled '\033' not '\e' for portability.

    Nicolas Pitre authored gitster committed
    Signed-off-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Nov 4, 2007
  1. @gitster

    fix display overlap between remote and local progress

    Nicolas Pitre authored gitster committed
    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: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Oct 17, 2007
  1. @spearce

    cope with multiple line breaks within sideband progress messages

    Nicolas Pitre authored spearce committed
    A single sideband packet may sometimes contain multiple lines of progress
    messages, but we prepend "remote: " only to the whole buffer which creates
    a messed up display in that case.  Make sure that the "remote: " prefix
    is applied to every remote lines.
    
    Signed-off-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commits on Oct 11, 2006
  1. atomic write for sideband remote messages

    Nicolas Pitre authored Junio C Hamano committed
    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: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Sep 10, 2006
  1. Move sideband server side support into reusable form.

    Junio C Hamano authored
    The server side support; this is just the very low level, and the
    caller needs to know which band it wants to send things out.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    (cherry picked from b786552b67878c7780c50def4c069d46dc54efbe commit)
  2. Move sideband client side support into reusable form.

    Junio C Hamano authored
    This moves the receiver side of the sideband support from
    fetch-clone.c to sideband.c and its header file, so that
    archiver protocol can use it.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Something went wrong with that request. Please try again.