Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Feb 11, 2015
  1. @gitster

    Merge branch 'jc/unused-symbols'

    gitster authored
    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 authored
    No external callers exist.
    Signed-off-by: Junio C Hamano <>
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
    * 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 authored
    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 4, 2013
  1. @gitster

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

    gitster authored
    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 Sep 9, 2013
  1. @gitster

    Merge branch 'jc/push-cas'

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

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

    gitster authored
    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 authored
    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 8, 2013
  1. @gitster

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

    gitster authored
    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 Mar 25, 2013
  1. @gitster

    Merge branch 'jc/push-follow-tag'

    gitster authored
    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 authored
    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 authored
    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 Oct 26, 2011
  1. @gitster

    Merge branch 'cn/fetch-prune'

    gitster authored
    * 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 Sep 12, 2011
  1. @gitster

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

    gitster authored
    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 Dec 26, 2009
  1. @gitster

    Merge branch 'sr/vcs-helper'

    gitster authored
    * sr/vcs-helper:
      tests: handle NO_PYTHON setting
      builtin-push: don't access freed transport->url
      Add Python support library for remote helpers
      Basic build infrastructure for Python scripts
      Allow helpers to report in "list" command that the ref is unchanged
      Fix various memory leaks in transport-helper.c
      Allow helper to map private ref names into normal names
      Add support for "import" helper command
      Allow specifying the remote helper in the url
      Add a config option for remotes to specify a foreign vcs
      Allow fetch to modify refs
      Use a function to determine whether a remote is valid
      Allow programs to not depend on remotes having urls
      Fix memory leak in helper method for disconnect
Commits on Jun 21, 2009
  1. @gitster

    Merge branch 'mg/pushurl'

    gitster authored
    * mg/pushurl:
      avoid NULL dereference on failed malloc
      builtin-remote: Make "remote -v" display push urls
      builtin-remote: Show push urls as well
      technical/api-remote: Describe new struct remote member pushurl
      t5516: Check pushurl config setting
      Allow push and fetch urls to be different
Commits on Jul 3, 2008
  1. @gitster

    Refactor "tracking statistics" code used by "git checkout"

    gitster authored
    People seem to like "Your branch is ahead by N commit" report made by
    "git checkout", but the interface into the statistics function was a bit
    clunky.  This splits the function into three parts:
     * The core "commit counting" function that takes "struct branch" and
       returns number of commits to show if we are ahead, behind or forked;
     * Convenience "stat formating" function that takes "struct branch" and
       formats the report into a given strbuf, using the above function;
     * "checkout" specific function that takes "branch_info" (type that is
       internal to checkout implementation), calls the above function and
       print the formatted result.
    in the hope that the former two can be more easily reusable.
    Signed-off-by: Junio C Hamano <>
Commits on May 25, 2008
  1. @gitster

    Merge branch 'db/clone-in-c'

    gitster authored
    * db/clone-in-c:
      Add test for cloning with "--reference" repo being a subset of source repo
      Add a test for another combination of --reference
      Test that --reference actually suppresses fetching referenced objects
      clone: fall back to copying if hardlinking fails
      builtin-clone.c: Need to closedir() in copy_or_link_directory()
      builtin-clone: fix initial checkout
      Build in clone
      Provide API access to init_db()
      Add a function to set a non-default work tree
      Allow for having for_each_ref() list extra refs
      Have a constant extern refspec for "--tags"
      Add a library function to add an alternate to the alternates file
      Add a lockfile function to append to a file
      Mark the list of refs to fetch as const
Commits on May 23, 2008
  1. @gitster

    Merge branch 'pb/push'

    gitster authored
    * pb/push:
      add special "matching refs" refspec
Commits on May 9, 2008
  1. @gitster

    Merge branch 'db/learn-HEAD'

    gitster authored
    * db/learn-HEAD:
      Make ls-remote http://... list HEAD, like for git://...
      Make walker.fetch_ref() take a struct ref.
Commits on Mar 23, 2008
  1. @gitster

    remote.c: Fix overtight refspec validation

    gitster authored
    We tightened the refspec validation code in an earlier commit ef00d15
    (Tighten refspec processing, 2008-03-17) per my suggestion, but the
    suggestion was misguided to begin with and it broke this usage:
        $ git push origin HEAD~12:master
    The syntax of push refspecs and fetch refspecs are similar in that they
    are both colon separated LHS and RHS (possibly prefixed with a + to
    force), but the similarity ends there.  For example, LHS in a push refspec
    can be anything that evaluates to a valid object name at runtime (except
    when colon and RHS is missing, or it is a glob), while it must be a
    valid-looking refname in a fetch refspec.  To validate them correctly, the
    caller needs to be able to say which kind of refspecs they are.  It is
    unreasonable to keep a single interface that cannot tell which kind it is
    dealing with, and ask it to behave sensibly.
    This commit separates the parsing of the two into different functions, and
    clarifies the code to implement the parsing proper (i.e. splitting into
    two parts, making sure both sides are wildcard or neither side is).
    This happens to also allow pushing a commit named with the esoteric "look
    for that string" syntax:
        $ git push ../test.git ':/remote.c: Fix overtight refspec:master'
    Signed-off-by: Junio C Hamano <>
Commits on Oct 28, 2007
  1. @gitster

    git-fetch: do not fail when remote branch disappears

    gitster authored
    When the branch named with branch.$name.merge is not covered by
    the fetch configuration for the remote repository named with
    branch.$name.remote, we automatically add that branch to the set
    of branches to be fetched.  However, if the remote repository
    does not have that branch (e.g. it used to exist, but got
    removed), this is not a reason to fail the git-fetch itself.
    The situation however will be noticed if git-fetch was called by
    git-pull, as the resulting FETCH_HEAD would not have any entry
    that is marked for merging.
    Acked-By: Daniel Barkalow <>
    Signed-off-by: Junio C Hamano <>
Something went wrong with that request. Please try again.