Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on May 6, 2015
  1. @gitster

    Merge branch 'bc/object-id'

    gitster authored
    Identify parts of the code that knows that we use SHA-1 hash to
    name our objects too much, and use (1) symbolic constants instead
    of hardcoded 20 as byte count and/or (2) use struct object_id
    instead of unsigned char [20] for object names.
    
    * bc/object-id:
      apply: convert threeway_stage to object_id
      patch-id: convert to use struct object_id
      commit: convert parts to struct object_id
      diff: convert struct combine_diff_path to object_id
      bulk-checkin.c: convert to use struct object_id
      zip: use GIT_SHA1_HEXSZ for trailers
      archive.c: convert to use struct object_id
      bisect.c: convert leaf functions to use struct object_id
      define utility functions for object IDs
      define a structure for object IDs
Commits on Apr 20, 2015
  1. @gitster

    Merge branch 'jc/push-cert'

    gitster authored
    The "git push --signed" protocol extension did not limit what the
    "nonce" that is a server-chosen string can contain or how long it
    can be, which was unnecessarily lax.  Limit both the length and the
    alphabet to a reasonably small space that can still have enough
    entropy.
    
    * jc/push-cert:
      push --signed: tighten what the receiving end can ask to sign
Commits on Apr 2, 2015
  1. @gitster

    Merge branch 'sb/atomic-push'

    gitster authored
    * sb/atomic-push:
      send-pack: unify error messages for unsupported capabilities
  2. @gitster

    push --signed: tighten what the receiving end can ask to sign

    gitster authored
    Instead of blindly trusting the receiving side to give us a sensible
    nonce to sign, limit the length (max 256 bytes) and the alphabet
    (alnum and a few selected punctuations, enough to encode in base64)
    that can be used in nonce.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  3. @gitster

    send-pack: unify error messages for unsupported capabilities

    Ralf Thielow authored gitster committed
    If --signed is not supported, the error message names the remote
    "receiving end". If --atomic is not supported, the error message
    names the remote "server". Unify the naming to "receiving end"
    as we're in the context of "push".
    
    Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Mar 14, 2015
  1. @bk2204 @gitster

    commit: convert parts to struct object_id

    bk2204 authored gitster committed
    Convert struct commit_graft and necessary local parts of commit.c.
    Also, convert several constants based on the hex length of an SHA-1 to
    use GIT_SHA1_HEXSZ, and move several magic constants into variables for
    readability.
    
    Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Feb 11, 2015
  1. @gitster

    Merge branch 'sb/atomic-push'

    gitster authored
    "git push" has been taught a "--atomic" option that makes push to
    update more than one ref an "all-or-none" affair.
    
    * sb/atomic-push:
      Document receive.advertiseatomic
      t5543-atomic-push.sh: add basic tests for atomic pushes
      push.c: add an --atomic argument
      send-pack.c: add --atomic command line argument
      send-pack: rename ref_update_to_be_sent to check_to_send_update
      receive-pack.c: negotiate atomic push support
      receive-pack.c: add execute_commands_atomic function
      receive-pack.c: move transaction handling in a central place
      receive-pack.c: move iterating over all commands outside execute_commands
      receive-pack.c: die instead of error in case of possible future bug
      receive-pack.c: shorten the execute_commands loop over all commands
Commits on Jan 8, 2015
  1. @rsahlberg @gitster

    send-pack.c: add --atomic command line argument

    rsahlberg authored gitster committed
    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: Ronnie Sahlberg <sahlberg@google.com>
    Signed-off-by: Stefan Beller <sbeller@google.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @stefanbeller @gitster

    send-pack: rename ref_update_to_be_sent to check_to_send_update

    stefanbeller authored gitster committed
    This renames ref_update_to_be_sent to check_to_send_update and inverts
    the meaning of the return value. Having the return value inverted we
    can have different values for the error codes. This is useful in a
    later patch when we want to know if we hit the CHECK_REF_STATUS_REJECTED
    case.
    
    Signed-off-by: Stefan Beller <sbeller@google.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Dec 29, 2014
  1. @bk2204 @gitster

    pack-objects: use --objects-edge-aggressive for shallow repos

    bk2204 authored gitster committed
    When fetching into or pushing from a shallow repository, we want to
    aggressively mark edges as uninteresting, since this decreases the pack
    size.  However, aggressively marking edges can negatively affect
    performance on large non-shallow repositories with lots of refs.
    
    Teach pack-objects a --shallow option to indicate that we're pushing
    from or fetching into a shallow repository.  Use
    --objects-edge-aggressive only for shallow repositories and otherwise
    use --objects-edge, which performs better in the general case.  Update
    the callers to pass the --shallow option when they are dealing with a
    shallow repository.
    
    Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Oct 8, 2014
  1. @gitster

    Merge branch 'jc/push-cert'

    gitster authored
    Allow "git push" request to be signed, so that it can be verified and
    audited, using the GPG signature of the person who pushed, that the
    tips of branches at a public repository really point the commits
    the pusher wanted to, without having to "trust" the server.
    
    * jc/push-cert: (24 commits)
      receive-pack::hmac_sha1(): copy the entire SHA-1 hash out
      signed push: allow stale nonce in stateless mode
      signed push: teach smart-HTTP to pass "git push --signed" around
      signed push: fortify against replay attacks
      signed push: add "pushee" header to push certificate
      signed push: remove duplicated protocol info
      send-pack: send feature request on push-cert packet
      receive-pack: GPG-validate push certificates
      push: the beginning of "git push --signed"
      pack-protocol doc: typofix for PKT-LINE
      gpg-interface: move parse_signature() to where it should be
      gpg-interface: move parse_gpg_output() to where it should be
      send-pack: clarify that cmds_sent is a boolean
      send-pack: refactor inspecting and resetting status and sending commands
      send-pack: rename "new_refs" to "need_pack_data"
      receive-pack: factor out capability string generation
      send-pack: factor out capability string generation
      send-pack: always send capabilities
      send-pack: refactor decision to send update per ref
      send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher
      ...
Commits on Sep 17, 2014
  1. @gitster

    signed push: fortify against replay attacks

    gitster authored
    In order to prevent a valid push certificate for pushing into an
    repository from getting replayed in a different push operation, send
    a nonce string from the receive-pack process and have the signer
    include it in the push certificate.  The receiving end uses an HMAC
    hash of the path to the repository it serves and the current time
    stamp, hashed with a secret seed (the secret seed does not have to
    be per-repository but can be defined in /etc/gitconfig) to generate
    the nonce, in order to ensure that a random third party cannot forge
    a nonce that looks like it originated from it.
    
    The original nonce is exported as GIT_PUSH_CERT_NONCE for the hooks
    to examine and match against the value on the "nonce" header in the
    certificate to notice a replay, but returned "nonce" header in the
    push certificate is examined by receive-pack and the result is
    exported as GIT_PUSH_CERT_NONCE_STATUS, whose value would be "OK"
    if the nonce recorded in the certificate matches what we expect, so
    that the hooks can more easily check.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Sep 15, 2014
  1. @gitster

    signed push: add "pushee" header to push certificate

    gitster 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: Junio C Hamano <gitster@pobox.com>
  2. @gitster

    signed push: remove duplicated protocol info

    gitster authored
    With the interim protocol, we used to send the update commands even
    though we already send a signed copy of the same information when
    push certificate is in use.  Update the send-pack/receive-pack pair
    not to do so.
    
    The notable thing on the receive-pack side is that it makes sure
    that there is no command sent over the traditional protocol packet
    outside the push certificate.  Otherwise a pusher can claim to be
    pushing one set of ref updates in the signed certificate while
    issuing commands to update unrelated refs, and such an update will
    evade later audits.
    
    Finally, start documenting the protocol.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  3. @gitster

    send-pack: send feature request on push-cert packet

    gitster authored
    We would want to update the interim protocol so that we do not send
    the usual update commands when the push certificate feature is in
    use, as the same information is in the certificate.  Once that
    happens, the push-cert packet may become the only protocol command,
    but then there is no packet to put the feature request behind, like
    we always did.
    
    As we have prepared the receiving end that understands the push-cert
    feature to accept the feature request on the first protocol packet
    (other than "shallow ", which was an unfortunate historical mistake
    that has to come before everything else), we can give the feature
    request on the push-cert packet instead of the first update protocol
    packet, in preparation for the next step to actually update to the
    final protocol.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  4. @gitster

    push: the beginning of "git push --signed"

    gitster 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
    	3793ac5... 12850be... 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
        audits.
    
    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: Junio C Hamano <gitster@pobox.com>
  5. @gitster

    send-pack: clarify that cmds_sent is a boolean

    gitster authored
    We use it to make sure that the feature request is sent only once on
    the very first request packet (ignoring the "shallow " line, which
    was an unfortunate mistake we cannot retroactively fix with existing
    receive-pack already deployed in the field) and we set it to "true"
    with cmds_sent++, not because we care about the actual number of
    updates sent but because it is merely an idiomatic way.
    
    Set it explicitly to one to clarify that the code that uses this
    variable only cares about its zero-ness.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  6. @gitster

    send-pack: refactor inspecting and resetting status and sending commands

    gitster authored
    The main loop over remote_refs list inspects the ref status
    to see if we need to generate pack data (i.e. a delete-only push
    does not need to send any additional data), resets it to "expecting
    the status report" state, and formats the actual update commands
    to be sent.
    
    Split the former two out of the main loop, as it will become
    conditional in later steps.
    
    Besides, we should have code that does real thing here, before the
    "Finally, tell the other end!" part ;-)
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  7. @gitster

    send-pack: rename "new_refs" to "need_pack_data"

    gitster authored
    The variable counts how many non-deleting command is being sent, but
    is only checked with 0-ness to decide if we need to send the pack
    data.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  8. @gitster

    send-pack: factor out capability string generation

    gitster authored
    A run of 'var ? " var" : ""' fed to a long printf string in a deeply
    nested block was hard to read.  Move it outside the loop and format
    it into a strbuf.
    
    As an added bonus, the trick to add "agent=<agent-name>" by using
    two conditionals is replaced by a more readable version.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  9. @gitster

    send-pack: always send capabilities

    gitster authored
    We tried to avoid sending one extra byte, NUL and nothing behind it
    to signal there is no protocol capabilities being sent, on the first
    command packet on the wire, but it just made the code look ugly.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  10. @gitster

    send-pack: refactor decision to send update per ref

    gitster authored
    A new helper function ref_update_to_be_sent() decides for each ref
    if the update is to be sent based on the status previously set by
    set_ref_status_for_push() and also if this is a mirrored push.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  11. @gitster

    send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher

    gitster authored
    20e8b46 (refactor ref status logic for pushing, 2010-01-08)
    restructured the code to set status for each ref to be pushed, but
    did not quite go far enough.  We inspect the status set earlier by
    set_refs_status_for_push() and then perform yet another update to
    the status of a ref with an otherwise OK status to be deleted to
    mark it with REF_STATUS_REJECT_NODELETE when the protocol tells us
    never to delete.
    
    Split the latter into a separate loop that comes before we enter the
    per-ref loop.  This way we would have one less condition to check in
    the main loop.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Aug 20, 2014
  1. @gitster

    run-command: introduce CHILD_PROCESS_INIT

    René Scharfe authored gitster committed
    Most struct child_process variables are cleared using memset first after
    declaration.  Provide a macro, CHILD_PROCESS_INIT, that can be used to
    initialize them statically instead.  That's shorter, doesn't require a
    function call and is slightly more readable (especially given that we
    already have STRBUF_INIT, ARGV_ARRAY_INIT etc.).
    
    Helped-by: Johannes Sixt <j6t@kdbg.org>
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jan 17, 2014
  1. @gitster

    Merge branch 'nd/shallow-clone'

    gitster authored
    Fetching from a shallow-cloned repository used to be forbidden,
    primarily because the codepaths involved were not carefully vetted
    and we did not bother supporting such usage. This attempts to allow
    object transfer out of a shallow-cloned repository in a controlled
    way (i.e. the receiver become a shallow repository with truncated
    history).
    
    * nd/shallow-clone: (31 commits)
      t5537: fix incorrect expectation in test case 10
      shallow: remove unused code
      send-pack.c: mark a file-local function static
      git-clone.txt: remove shallow clone limitations
      prune: clean .git/shallow after pruning objects
      clone: use git protocol for cloning shallow repo locally
      send-pack: support pushing from a shallow clone via http
      receive-pack: support pushing to a shallow clone via http
      smart-http: support shallow fetch/clone
      remote-curl: pass ref SHA-1 to fetch-pack as well
      send-pack: support pushing to a shallow clone
      receive-pack: allow pushes that update .git/shallow
      connected.c: add new variant that runs with --shallow-file
      add GIT_SHALLOW_FILE to propagate --shallow-file to subprocesses
      receive/send-pack: support pushing from a shallow clone
      receive-pack: reorder some code in unpack()
      fetch: add --update-shallow to accept refs that update .git/shallow
      upload-pack: make sure deepening preserves shallow roots
      fetch: support fetching from a shallow repository
      clone: support remote shallow repository
      ...
Commits on Jan 6, 2014
  1. @gitster

    send-pack.c: mark a file-local function static

    Ramsay Jones authored gitster committed
    Commit f2c681c ("send-pack: support pushing from a shallow clone
    via http", 05-12-2013) adds the 'advertise_shallow_grafts_buf'
    function as an external symbol.
    
    Noticed by sparse. ("'advertise_shallow_grafts_buf' was not declared.
    Should it be static?")
    
    Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Dec 17, 2013
  1. @gitster

    Merge branch 'cc/starts-n-ends-with'

    gitster authored
    Remove a few duplicate implementations of prefix/suffix comparison
    functions, and rename them to starts_with and ends_with.
    
    * cc/starts-n-ends-with:
      replace {pre,suf}fixcmp() with {starts,ends}_with()
      strbuf: introduce starts_with() and ends_with()
      builtin/remote: remove postfixcmp() and use suffixcmp() instead
      environment: normalize use of prefixcmp() by removing " != 0"
Commits on Dec 11, 2013
  1. @pclouds @gitster

    send-pack: support pushing from a shallow clone via http

    pclouds authored gitster committed
    Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @pclouds @gitster

    receive/send-pack: support pushing from a shallow clone

    pclouds authored gitster committed
    Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  3. @pclouds @gitster

    remote.h: replace struct extra_have_objects with struct sha1_array

    pclouds authored gitster committed
    The latter can do everything the former can and is used in many more
    places.
    
    Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Dec 5, 2013
  1. @chriscool @gitster

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

    chriscool authored gitster committed
    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>
Commits on Nov 25, 2013
  1. @carlosmn @gitster

    send-pack: don't send a thin pack to a server which doesn't support it

    carlosmn authored gitster committed
    Up to now git has assumed that all servers are able to fix thin
    packs. This is however not always the case.
    
    Document the 'no-thin' capability and prevent send-pack from generating
    a thin pack if the server advertises it.
    
    Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
    Helped-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Oct 30, 2013
  1. @gitster

    Merge branch 'jl/pack-transfer-avoid-double-close'

    gitster authored
    The codepath that send_pack() calls pack_objects() mistakenly
    closed the same file descriptor twice, leading to potentially
    closing a wrong file descriptor that was opened in the meantime.
    
    * jl/pack-transfer-avoid-double-close:
      Clear fd after closing to avoid double-close error
Commits on Oct 23, 2013
  1. @jensl @gitster

    Clear fd after closing to avoid double-close error

    jensl authored gitster committed
    In send_pack(), clear the fd passed to pack_objects() by setting
    it to -1, since pack_objects() closes the fd (via a call to
    run_command()).  Likewise, in get_pack(), clear the fd passed to
    run_command().
    
    Not doing so risks having git_transport_push(), caller of
    send_pack(), closing the fd again, possibly incorrectly closing
    some other open file; or similarly with fetch_refs_from_pack(),
    indirect caller of get_pack().
    
    Signed-off-by: Jens Lindström <jl@opera.com>
    Acked-by: Jeff King <peff@peff.net>
    Acked-by: Duy Nguyen <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jul 23, 2013
  1. @gitster

    push --force-with-lease: tie it all together

    gitster authored
    This teaches the deepest part of the callchain for "git push" (and
    "git send-pack") to enforce "the old value of the ref must be this,
    otherwise fail this push" (aka "compare-and-swap" / "--lockref").
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Something went wrong with that request. Please try again.