1. 19 Aug, 2015 1 commit
  2. 08 Jan, 2015 1 commit
    • Ronnie Sahlberg's avatar
      send-pack.c: add --atomic command line argument · 4ff17f10
      Ronnie Sahlberg authored
      This adds support to send-pack to negotiate and use atomic pushes
      iff the server supports it. Atomic pushes are activated by a new command
      line flag --atomic.
      In order to do this we also need to change the semantics for send_pack()
      slightly. The existing send_pack() function actually doesn't send all the
      refs back to the server when multiple refs are involved, for example
      when using --all. Several of the failure modes for pushes can already be
      detected locally in the send_pack client based on the information from the
      initial server side list of all the refs as generated by receive-pack.
      Any such refs that we thus know would fail to push are thus pruned from
      the list of refs we send to the server to update.
      For atomic pushes, we have to deal thus with both failures that are detected
      locally as well as failures that are reported back from the server. In order
      to do so we treat all local failures as push failures too.
      We introduce a new status code REF_STATUS_ATOMIC_PUSH_FAILED so we can
      flag all refs that we would normally have tried to push to the server
      but we did not due to local failures. This is to improve the error message
      back to the end user to flag that "these refs failed to update since the
      atomic push operation failed."
      Signed-off-by: default avatarRonnie Sahlberg <sahlberg@google.com>
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  3. 15 Sep, 2014 2 commits
    • Junio C Hamano's avatar
      signed push: add "pushee" header to push certificate · 9be89160
      Junio C Hamano authored
      Record the URL of the intended recipient for a push (after
      anonymizing it if it has authentication material) on a new "pushee
      URL" header.  Because the networking configuration (SSH-tunnels,
      proxies, etc.) on the pushing user's side varies, the receiving
      repository may not know the single canonical URL all the pushing
      users would refer it as (besides, many sites allow pushing over
      ssh://host/path and https://host/path protocols to the same
      repository but with different local part of the path).  So this
      value may not be reliably used for replay-attack prevention
      purposes, but this will still serve as a human readable hint to
      identify the repository the certificate refers to.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Junio C Hamano's avatar
      push: the beginning of "git push --signed" · a85b377d
      Junio C Hamano authored
      While signed tags and commits assert that the objects thusly signed
      came from you, who signed these objects, there is not a good way to
      assert that you wanted to have a particular object at the tip of a
      particular branch.  My signing v2.0.1 tag only means I want to call
      the version v2.0.1, and it does not mean I want to push it out to my
      'master' branch---it is likely that I only want it in 'maint', so
      the signature on the object alone is insufficient.
      The only assurance to you that 'maint' points at what I wanted to
      place there comes from your trust on the hosting site and my
      authentication with it, which cannot easily audited later.
      Introduce a mechanism that allows you to sign a "push certificate"
      (for the lack of better name) every time you push, asserting that
      what object you are pushing to update which ref that used to point
      at what other object.  Think of it as a cryptographic protection for
      ref updates, similar to signed tags/commits but working on an
      orthogonal axis.
      The basic flow based on this mechanism goes like this:
       1. You push out your work with "git push --signed".
       2. The sending side learns where the remote refs are as usual,
          together with what protocol extension the receiving end
          supports.  If the receiving end does not advertise the protocol
          extension "push-cert", an attempt to "git push --signed" fails.
          Otherwise, a text file, that looks like the following, is
          prepared in core:
      	certificate version 0.1
      	pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
      	7339ca65... 21580ecb... refs/heads/master
      	3793ac56... 12850bec... refs/heads/next
          The file begins with a few header lines, which may grow as we
          gain more experience.  The 'pusher' header records the name of
          the signer (the value of user.signingkey configuration variable,
          falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
          certificate generation.  After the header, a blank line follows,
          followed by a copy of the protocol message lines.
          Each line shows the old and the new object name at the tip of
          the ref this push tries to update, in the way identical to how
          the underlying "git push" protocol exchange tells the ref
          updates to the receiving end (by recording the "old" object
          name, the push certificate also protects against replaying).  It
          is expected that new command packet types other than the
          old-new-refname kind will be included in push certificate in the
          same way as would appear in the plain vanilla command packets in
          unsigned pushes.
          The user then is asked to sign this push certificate using GPG,
          formatted in a way similar to how signed tag objects are signed,
          and the result is sent to the other side (i.e. receive-pack).
          In the protocol exchange, this step comes immediately before the
          sender tells what the result of the push should be, which in
          turn comes before it sends the pack data.
       3. When the receiving end sees a push certificate, the certificate
          is written out as a blob.  The pre-receive hook can learn about
          the certificate by checking GIT_PUSH_CERT environment variable,
          which, if present, tells the object name of this blob, and make
          the decision to allow or reject this push.  Additionally, the
          post-receive hook can also look at the certificate, which may be
          a good place to log all the received certificates for later
      Because a push certificate carry the same information as the usual
      command packets in the protocol exchange, we can omit the latter
      when a push certificate is in use and reduce the protocol overhead.
      This however is not included in this patch to make it easier to
      review (in other words, the series at this step should never be
      released without the remainder of the series, as it implements an
      interim protocol that will be incompatible with the final one).
      As such, the documentation update for the protocol is left out of
      this step.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  4. 11 Dec, 2013 1 commit
  5. 18 Oct, 2010 1 commit
  6. 28 Feb, 2010 1 commit
    • Larry D'Anna's avatar
      git-push: make git push --porcelain print "Done" · 77555854
      Larry D'Anna authored
      The script calling git push --porcelain --dry-run can see clearly from the
      output if an update was rejected.  However, it will probably need to distinguish
      this condition from the push failing for other reasons, such as the remote not
      being reachable.
      This patch modifies git push --porcelain to print "Done" after the rest of its
      output unless any errors have occurred.  For the purpose of the "Done" line,
      knowing a ref will be rejected in a --dry-run does not count as an error.
      Actual rejections in non --dry-run pushes do count as errors.
      Signed-off-by: default avatarLarry D'Anna <larry@elder-gods.org>
      Acked-by: Ray's avatarTay Ray Chuan <rctay89@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  7. 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>
  8. 06 Aug, 2009 1 commit
  9. 02 May, 2009 1 commit
    • Nicolas Pitre's avatar
      allow OFS_DELTA objects during a push · b74fce16
      Nicolas Pitre authored
      The fetching of OFS_DELTA objects has been negotiated between both peers
      since git version 1.4.4.  However, this was missing from the push side
      where every OFS_DELTA objects were always converted to REF_DELTA objects
      causing an increase in transferred data.
      To fix this, both the client and the server processes have to be
      modified: the former to invoke pack-objects with --delta-base-offset
      when the server provides the ofs-delta capability, and the later to send
      that capability when OFS_DELTA objects are allowed as already indicated
      by the repack.usedeltabaseoffset config variable which is TRUE by
      default since git v1.6.0.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  10. 09 Mar, 2009 1 commit
  11. 10 Nov, 2007 1 commit
    • Andy Whitcroft's avatar
      Teach send-pack a mirror mode · 28b9d6e5
      Andy Whitcroft authored
      Existing "git push --all" is almost perfect for backing up to
      another repository, except that "--all" only means "all
      branches" in modern git, and it does not delete old branches and
      tags that exist at the back-up repository that you have removed
      from your local repository.
      This teaches "git-send-pack" a new "--mirror" option.  The
      difference from the "--all" option are that (1) it sends all
      refs, not just branches, and (2) it deletes old refs you no
      longer have on the local side from the remote side.
      Original patch by Junio C Hamano.
      Signed-off-by: default avatarAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  12. 03 Nov, 2007 1 commit