Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on May 22, 2015
  1. @peff @gitster

    remote.c: add branch_get_push

    peff committed with gitster
    In a triangular workflow, the place you pull from and the
    place you push to may be different. As we have
    branch_get_upstream for the former, this patch adds
    branch_get_push for the latter (and as the former implements
    @{upstream}, so will this implement @{push} in a future
    Note that the memory-handling for the return value bears
    some explanation. Some code paths require allocating a new
    string, and some let us return an existing string. We should
    provide a consistent interface to the caller, so it knows
    whether to free the result or not.
    We could do so by xstrdup-ing any existing strings, and
    having the caller always free. But that makes us
    inconsistent with branch_get_upstream, so we would prefer to
    simply take ownership of the resulting string. We do so by
    storing it inside the "struct branch", just as we do with
    the upstream refname (in that case we compute it when the
    branch is created, but there's no reason not to just fill
    it in lazily in this case).
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
  2. @peff @gitster

    remote.c: return upstream name from stat_tracking_info

    peff committed with gitster
    After calling stat_tracking_info, callers often want to
    print the name of the upstream branch (in addition to the
    tracking count). To do this, they have to access
    branch->merge->dst[0] themselves. This is not wrong, as the
    return value from stat_tracking_info tells us whether we
    have an upstream branch or not. But it is a bit leaky, as we
    make an assumption about how it calculated the upstream
    Instead, let's add an out-parameter that lets the caller
    know the upstream name we found.
    As a bonus, we can get rid of the unusual tri-state return
    from the function. We no longer need to use it to
    differentiate between "no tracking config" and "tracking ref
    does not exist" (since you can check the upstream_name for
    that), so we can just use the usual 0/-1 convention for
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on May 21, 2015
  1. @peff @gitster

    remote.c: report specific errors from branch_get_upstream

    peff committed with gitster
    When the previous commit introduced the branch_get_upstream
    helper, there was one call-site that could not be converted:
    the one in sha1_name.c, which gives detailed error messages
    for each possible failure.
    Let's teach the helper to optionally report these specific
    errors. This lets us convert another callsite, and means we
    can use the helper in other locations that want to give the
    same error messages.
    The logic and error messages come straight from sha1_name.c,
    with the exception that we start each error with a lowercase
    letter, as is our usual style (note that a few tests need
    updated as a result).
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
  2. @peff @gitster

    remote.c: introduce branch_get_upstream helper

    peff committed with gitster
    All of the information needed to find the @{upstream} of a
    branch is included in the branch struct, but callers have to
    navigate a series of possible-NULL values to get there.
    Let's wrap that logic up in an easy-to-read helper.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
  3. @peff @gitster

    remote.c: provide per-branch pushremote name

    peff committed with gitster
    When remote.c loads its config, it records the
    branch.*.pushremote for the current branch along with the
    global remote.pushDefault value, and then binds them into a
    single value: the default push for the current branch. We
    then pass this value (which may be NULL) to remote_get_1
    when looking up a remote for push.
    This has a few downsides:
      1. It's confusing. The early-binding of the "current
         value" led to bugs like the one fixed by 98b406f
         (remote: handle pushremote config in any order,
         2014-02-24). And the fact that pushremotes fall back to
         ordinary remotes is not explicit at all; it happens
         because remote_get_1 cannot tell the difference between
         "we are not asking for the push remote" and "there is
         no push remote configured".
      2. It throws away intermediate data. After read_config()
         finishes, we have no idea what the value of
         remote.pushDefault was, because the string has been
         overwritten by the current branch's
      3. It doesn't record other data. We don't note the
         branch.*.pushremote value for anything but the current
    Let's make this more like the fetch-remote config. We'll
    record the pushremote for each branch, and then explicitly
    compute the correct remote for the current branch at the
    time of reading.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
  4. @peff @gitster

    remote.c: hoist branch.*.remote lookup out of remote_get_1

    peff committed with gitster
    We'll want to use this logic as a fallback when looking up
    the pushremote, so let's pull it out into its own function.
    We don't technically need to make this available outside of
    remote.c, but doing so will provide a consistent API with
    pushremote_for_branch, which we will add later.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
  5. @peff @gitster

    remote.c: drop "remote" pointer from "struct branch"

    peff committed with gitster
    When we create each branch struct, we fill in the
    "remote_name" field from the config, and then fill in the
    actual "remote" field (with a "struct remote") based on that
    name. However, it turns out that nobody really cares about
    the latter field. The only two sites that access it at all
      1. git-merge, which uses it to notice when the branch does
         not have a remote defined. But we can easily replace this
         with looking at remote_name instead.
      2. remote.c itself, when setting up the @{upstream} merge
         config. But we don't need to save the "remote" in the
         "struct branch" for that; we can just look it up for
         the duration of the operation.
    So there is no need to have both fields; they are redundant
    with each other (the struct remote contains the name, or you
    can look up the struct from the name). It would be nice to
    simplify this, especially as we are going to add matching
    pushremote config in a future patch (and it would be nice to
    keep them consistent).
    So which one do we keep and which one do we get rid of?
    If we had a lot of callers accessing the struct, it would be
    more efficient to keep it (since you have to do a lookup to
    go from the name to the struct, but not vice versa). But we
    don't have a lot of callers; we have exactly one, so
    efficiency doesn't matter. We can decide this based on
    simplicity and readability.
    And the meaning of the struct value is somewhat unclear. Is
    it always the remote matching remote_name? If remote_name is
    NULL (i.e., no per-branch config), does the struct fall back
    to the "origin" remote, or is it also NULL? These questions
    will get even more tricky with pushremotes, whose fallback
    behavior is more complicated. So let's just store the name,
    which pretty clearly represents the branch.*.remote config.
    Any lookup or fallback behavior can then be implemented in
    helper functions.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 11, 2015
  1. @gitster

    Merge branch 'jc/unused-symbols'

    gitster committed
    Mark file-local symbols as "static", and drop functions that nobody
    * jc/unused-symbols:
      shallow.c: make check_shallow_file_for_update() static
      remote.c: make clear_cas_option() static
      urlmatch.c: make match_urls() static
      revision.c: make save_parents() and free_saved_parents() static
      line-log.c: make line_log_data_init() static
      pack-bitmap.c: make pack_bitmap_filename() static
      prompt.c: remove git_getpass() nobody uses
      http.c: make finish_active_slot() and handle_curl_result() static
Commits on Jan 15, 2015
  1. @gitster

    remote.c: make clear_cas_option() static

    gitster committed
    No external callers exist.
    Signed-off-by: Junio C Hamano <>
Commits on Jan 8, 2015
  1. @rsahlberg @gitster

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

    rsahlberg committed with gitster
    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 <>
    Signed-off-by: Stefan Beller <>
    Signed-off-by: Junio C Hamano <>
Commits on Jul 30, 2014
  1. @piki @gitster

    use a hashmap to make remotes faster

    piki committed with gitster
    Remotes are stored as an array, so looking one up or adding one without
    duplication is an O(n) operation.  Reading an entire config file full of
    remotes is O(n^2) in the number of remotes.  For a repository with tens of
    thousands of remotes, the running time can hit multiple minutes.
    Hash tables are way faster.  So we add a hashmap from remote name to
    struct remote and use it for all lookups.  The time to add a new remote to
    a repo that already has 50,000 remotes drops from ~2 minutes to < 1
    We retain the old array of remotes so iterators proceed in config-file
    Signed-off-by: Patrick Reynolds <>
    Reviewed-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Mar 5, 2014
  1. @peff @gitster

    push: detect local refspec errors early

    peff committed with gitster
    When pushing, we do not even look at our push refspecs until
    after we have made contact with the remote receive-pack and
    gotten its list of refs. This means that we may go to some
    work, including asking the user to log in, before realizing
    we have simple errors like "git push origin matser".
    We cannot catch all refspec problems, since fully evaluating
    the refspecs requires knowing what the remote side has. But
    we can do a quick sanity check of the local side and catch a
    few simple error cases.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Jan 17, 2014
  1. @gitster

    Merge branch 'nd/shallow-clone'

    gitster committed
    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
    * 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 Dec 27, 2013
  1. @gitster

    Merge branch 'jc/push-refmap'

    gitster committed
    Make "git push origin master" update the same ref that would be
    updated by our 'master' when "git push origin" (no refspecs) is run
    while the 'master' branch is checked out, which makes "git push"
    more symmetric to "git fetch" and more usable for the triangular
    * jc/push-refmap:
      push: also use "upstream" mapping when pushing a single ref
      push: use remote.$name.push as a refmap
      builtin/push.c: use strbuf instead of manual allocation
Commits on Dec 11, 2013
  1. @pclouds @gitster

    fetch: support fetching from a shallow repository

    pclouds committed with gitster
    This patch just put together pieces from the 8 steps patch. We stop at
    step 7 and reject refs that require new shallow commits.
    Note that, by rejecting refs that require new shallow commits, we
    leave dangling objects in the repo, which become "object islands" by
    the next "git fetch" of the same source.
    If the first fetch our "ours" set is zero and we do practically
    nothing at step 7, "ours" is full at the next fetch and we may need to
    walk through commits for reachability test. Room for improvement.
    Signed-off-by: Nguyễn Thái Ngọc Duy <>
    Signed-off-by: Junio C Hamano <>
  2. @pclouds @gitster

    connect.c: teach get_remote_heads to parse "shallow" lines

    pclouds committed with gitster
    No callers pass a non-empty pointer as shallow_points at this
    stage. As a result, all clients still refuse to talk to shallow
    repository on the other end.
    Signed-off-by: Nguyễn Thái Ngọc Duy <>
    Signed-off-by: Junio C Hamano <>
  3. @pclouds @gitster

    remote.h: replace struct extra_have_objects with struct sha1_array

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

    push: use remote.$name.push as a refmap

    gitster committed
    Since f269048 (fetch: opportunistically update tracking refs,
    2013-05-11), we stopped taking a non-storing refspec given on the
    command line of "git fetch" literally, and instead started mapping
    it via remote.$name.fetch refspecs.  This allows
        $ git fetch origin master
    from the 'origin' repository, which is configured with
        [remote "origin"]
            fetch = +refs/heads/*:refs/remotes/origin/*
    to update refs/remotes/origin/master with the result, as if the
    command line were
        $ git fetch origin +master:refs/remotes/origin/master
    to reduce surprises and improve usability.  Before that change, a
    refspec on the command line without a colon was only to fetch the
    history and leave the result in FETCH_HEAD, without updating the
    remote-tracking branches.
    When you are simulating a fetch from you by your mothership with a
    push by you into your mothership, instead of having:
        [remote "satellite"]
            fetch = +refs/heads/*:refs/remotes/satellite/*
    on the mothership repository and running:
        mothership$ git fetch satellite
    you would have:
        [remote "mothership"]
            push = +refs/heads/*:refs/remotes/satellite/*
    on your satellite machine, and run:
        satellite$ git push mothership
    Because we so far did not make the corresponding change to the push
    side, this command:
        satellite$ git push mothership master
    does _not_ allow you on the satellite to only push 'master' out but
    still to the usual destination (i.e. refs/remotes/satellite/master).
    Implement the logic to map an unqualified refspec given on the
    command line via the remote.$name.push refspec.  This will bring a
    bit more symmetry between "fetch" and "push".
    Signed-off-by: Junio C Hamano <>
Commits on Oct 30, 2013
  1. @mhagger @gitster

    ref_remove_duplicates(): simplify loop logic

    mhagger committed with gitster
    Change the loop body into the more straightforward
    * remove item from the front of the old list
    * if necessary, add it to the tail of the new list
    and return a pointer to the new list (even though it is currently
    always the same as the input argument, because the first element in
    the list is currently never deleted).
    Signed-off-by: Michael Haggerty <>
    Signed-off-by: Junio C Hamano <>
Commits on Sep 9, 2013
  1. @gitster

    Merge branch 'jc/push-cas'

    gitster committed
    Allow a safer "rewind of the remote tip" push than blind "--force",
    by requiring that the overwritten remote ref to be unchanged since
    the new history to replace it was prepared.
    The machinery is more or less ready.  The "--force" option is again
    the big red button to override any safety, thanks to J6t's sanity
    (the original round allowed --lockref to defeat --force).
    The logic to choose the default implemented here is fragile
    (e.g. "git fetch" after seeing a failure will update the
    remote-tracking branch and will make the next "push" pass,
    defeating the safety pretty easily).  It is suitable only for the
    simplest workflows, and it may hurt users more than it helps them.
    * jc/push-cas:
      push: teach --force-with-lease to smart-http transport
      send-pack: fix parsing of --force-with-lease option
      t5540/5541: smart-http does not support "--force-with-lease"
      t5533: test "push --force-with-lease"
      push --force-with-lease: tie it all together
      push --force-with-lease: implement logic to populate old_sha1_expect[]
      remote.c: add command line option parser for "--force-with-lease"
      builtin/push.c: use OPT_BOOL, not OPT_BOOLEAN
      cache.h: move remote/connect API out of it
Commits on Jul 23, 2013
  1. @gitster

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

    gitster committed
    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 <>
  2. @gitster

    push --force-with-lease: implement logic to populate old_sha1_expect[]

    gitster committed
    This plugs the push_cas_option data collected by the command line
    option parser to the transport system with a new function
    apply_push_cas(), which is called after match_push_refs() has
    already been called.
    At this point, we know which remote we are talking to, and what
    remote refs we are going to update, so we can fill in the details
    that may have been missing from the command line, such as
     (1) what abbreviated refname the user gave us matches the actual
         refname at the remote; and
     (2) which remote-tracking branch in our local repository to read
         the value of the object to expect at the remote.
    to populate the old_sha1_expect[] field of each of the remote ref.
    As stated in the documentation, the use of remote-tracking branch
    as the default is a tentative one, and we may come up with a better
    logic as we gain experience.
    Still nobody uses this information, which is the topic of the next
    Signed-off-by: Junio C Hamano <>
  3. @gitster

    remote.c: add command line option parser for "--force-with-lease"

    gitster committed
    Update "git push" and "git send-pack" to parse this commnd line
    The intended sematics is:
     * "--force-with-lease" alone, without specifying the details, will
       protect _all_ remote refs that are going to be updated by
       requiring their current value to be the same as some reasonable
       default, unless otherwise specified;
     * "--force-with-lease=refname", without specifying the expected
       value, will protect that refname, if it is going to be updated,
       by requiring its current value to be the same as some reasonable
     * "--force-with-lease=refname:value" will protect that refname, if
       it is going to be updated, by requiring its current value to be
       the same as the specified value; and
     * "--no-force-with-lease" will cancel all the previous --force-with-lease on the
       command line.
    For now, "some reasonable default" is tentatively defined as "the
    value of the remote-tracking branch we have for the ref of the
    remote being updated", and it is an error if we do not have such a
    remote-tracking branch.  But this is known to be fragile, its use is
    not yet recommended, and hopefully we will find more reasonable
    default as we gain experience with this feature.  The manual marks
    the feature as experimental unless the expected value is specified
    explicitly for this reason.
    Because the command line options are parsed _before_ we know which
    remote we are pushing to, there needs further processing to the
    parsed data after we instantiate the transport object to:
     * expand "refname" given by the user to a full refname to be
       matched with the list of "struct ref" used in match_push_refs()
       and set_ref_status_for_push(); and
     * learning the actual local ref that is the remote-tracking branch
       for the specified remote ref.
    Further, some processing need to be deferred until we find the set
    of remote refs and match_push_refs() returns in order to find the
    ones that need to be checked after explicit ones have been processed
    for "--force-with-lease" (no specific details).
    These post-processing will be the topic of the next patch.
    This option was originally called "cas" (for "compare and swap"),
    the name which nobody liked because it was too technical.  The
    second attempt called it "lockref" (because it is conceptually like
    pushing after taking a lock) but the word "lock" was hated because
    it implied that it may reject push by others, which is not the way
    this option works.  This round calls it "force-with-lease".  You
    assume you took the lease on the ref when you fetched to decide what
    the rebased history should be, and you can push back only if the
    lease has not been broken.
    Signed-off-by: Junio C Hamano <>
Commits on Jul 18, 2013
  1. @gitster

    fetch: make --prune configurable

    Michael Schubert committed with gitster
    Without "git fetch --prune", remote-tracking branches for a branch
    the other side already has removed will stay forever.  Some people
    want to always run "git fetch --prune".
    To accommodate users who want to either prune always or when fetching
    from a particular remote, add two new configuration variables
    "fetch.prune" and "remote.<name>.prune":
     - "fetch.prune" allows to enable prune for all fetch operations.
     - "remote.<name>.prune" allows to change the behaviour per remote.
    The latter will naturally override the former, and the --[no-]prune
    option from the command line will override the configured default.
    Since --prune is a potentially destructive operation (Git doesn't
    keep reflogs for deleted references yet), we don't want to prune
    without users consent, so this configuration will not be on by
    Helped-by: Junio C Hamano <>
    Signed-off-by: Michael Schubert <>
    Signed-off-by: Junio C Hamano <>
Commits on Jul 8, 2013
  1. @gitster

    cache.h: move remote/connect API out of it

    gitster committed
    The definition of "struct ref" in "cache.h", a header file so
    central to the system, always confused me.  This structure is not
    about the local ref used by sha1-name API to name local objects.
    It is what refspecs are expanded into, after finding out what refs
    the other side has, to define what refs are updated after object
    transfer succeeds to what values.  It belongs to "remote.h" together
    with "struct refspec".
    While we are at it, also move the types and functions related to the
    Git transport connection to a new header file connect.h
    Signed-off-by: Junio C Hamano <>
Commits on Apr 2, 2013
  1. @artagnon @gitster

    remote.c: introduce a way to have different remotes for fetch/push

    artagnon committed with gitster
    Currently, do_push() in push.c calls remote_get(), which gets the
    configured remote for fetching and pushing.  Replace this call with a
    call to pushremote_get() instead, a new function that will return the
    remote configured specifically for pushing.  This function tries to
    work with the string pushremote_name, before falling back to the
    codepath of remote_get().  This patch has no visible impact, but
    serves to enable future patches to introduce configuration variables
    to set pushremote_name.  For example, you can now do the following in
        if (!strcmp(key, "remote.pushdefault"))
           git_config_string(&pushremote_name, key, value);
    Then, pushes will automatically go to the remote specified by
    Signed-off-by: Ramkumar Ramachandra <>
    Reviewed-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Mar 25, 2013
  1. @gitster

    Merge branch 'jc/push-follow-tag'

    gitster committed
    The new "--follow-tags" option tells "git push" to push relevant
    annotated tags when pushing branches out.
    * jc/push-follow-tag:
      push: --follow-tags
      commit.c: use clear_commit_marks_many() in in_merge_bases_many()
      commit.c: add in_merge_bases_many()
      commit.c: add clear_commit_marks_many()
Commits on Mar 5, 2013
  1. @gitster

    push: --follow-tags

    gitster committed
    The new option "--follow-tags" tells "git push" to push annotated
    tags that are missing from the other side and that can be reached by
    the history that is otherwise pushed out.
    For example, if you are using the "simple", "current", or "upstream"
    push, you would ordinarily push the history leading to the commit at
    your current HEAD and nothing else.  With this option, you would
    also push all annotated tags that can be reached from that commit to
    the other side.
    Signed-off-by: Junio C Hamano <>
Commits on Feb 7, 2013
  1. @gitster

    fetch: fetch objects by their exact SHA-1 object names

    gitster committed
    Teach "git fetch" to accept an exact SHA-1 object name the user may
    obtain out of band on the LHS of a pathspec, and send it on a "want"
    message when the server side advertises the allow-tip-sha1-in-want
    Signed-off-by: Junio C Hamano <>
Commits on May 22, 2012
  1. @peff @gitster

    add sorting infrastructure for list refs

    peff committed with gitster
    Since we store lists of refs as linked lists, we can use
    llist_mergesort to efficiently sort them.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 23, 2012
  1. @felipec @gitster

    push: add '--prune' option

    felipec committed with gitster
    When pushing groups of refs to a remote, there is no simple way to remove
    old refs that still exist at the remote that is no longer updated from us.
    This will allow us to remove such refs from the remote.
    With this change, running this command
     $ git push --prune remote refs/heads/*:refs/remotes/laptop/*
    removes refs/remotes/laptop/foo from the remote if we do not have branch
    "foo" locally anymore.
    Signed-off-by: Felipe Contreras <>
    Signed-off-by: Junio C Hamano <>
Commits on Oct 26, 2011
  1. @gitster

    Merge branch 'cn/fetch-prune'

    gitster committed
    * cn/fetch-prune:
      fetch: treat --tags like refs/tags/*:refs/tags/* when pruning
      fetch: honor the user-provided refspecs when pruning refs
      remote: separate out the remote_find_tracking logic into query_refspecs
      t5510: add tests for fetch --prune
      fetch: free all the additional refspecs
Commits on Oct 16, 2011
  1. @carlosmn @gitster

    fetch: honor the user-provided refspecs when pruning refs

    carlosmn committed with gitster
    If the user gave us refspecs on the command line, we should use those
    when deciding whether to prune a ref instead of relying on the
    refspecs in the config.
    Previously, running
        git fetch --prune origin refs/heads/master:refs/remotes/origin/master
    would delete every other ref under the origin namespace because we
    were using the refspec to filter the available refs but using the
    configured refspec to figure out if a ref had been deleted on the
    remote. This is clearly the wrong thing to do.
    Change prune_refs and get_stale_heads to simply accept a list of
    references and a list of refspecs. The caller of either function needs
    to decide what refspecs should be used to decide whether a ref is
    Signed-off-by: Carlos Martín Nieto <>
    Signed-off-by: Junio C Hamano <>
Commits on Sep 12, 2011
  1. @gitster

    rename "match_refs()" to "match_push_refs()"

    gitster committed
    Yes, there is a warning that says the function is only used by push in big
    red letters in front of this function, but it didn't say a more important
    thing it should have said: what the function is for and what it does.
    Rename it and document it to avoid future confusion.
    Signed-off-by: Junio C Hamano <>
Commits on Jun 7, 2011
  1. @peff @gitster

    make copy_ref globally available

    peff committed with gitster
    This is a useful function, and we have already made the
    similar alloc_ref and copy_ref_list available.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Something went wrong with that request. Please try again.