Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Jan 17, 2014

  1. Junio C Hamano

    Merge branch 'nd/shallow-clone'

    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
      ...
    authored January 17, 2014

Dec 27, 2013

  1. Junio C Hamano

    Merge branch 'jc/push-refmap'

    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
    workflow.
    
    * 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
    authored December 27, 2013

Dec 04, 2013

  1. Junio C Hamano

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

    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 <gitster@pobox.com>
    authored December 03, 2013

Sep 09, 2013

  1. Junio C Hamano

    Merge branch 'jc/push-cas'

    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
    authored September 09, 2013

Jul 23, 2013

  1. Junio C Hamano

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

    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>
    authored July 08, 2013
  2. Junio C Hamano

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

    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
    patch.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored July 09, 2013
  3. Junio C Hamano

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

    Update "git push" and "git send-pack" to parse this commnd line
    option.
    
    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
       default.
    
     * "--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 <gitster@pobox.com>
    authored July 08, 2013

Jul 08, 2013

  1. Junio C Hamano

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

    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 <gitster@pobox.com>
    authored July 08, 2013

Mar 25, 2013

  1. Junio C Hamano

    Merge branch 'jc/push-follow-tag'

    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()
    authored March 25, 2013

Mar 05, 2013

  1. Junio C Hamano

    push: --follow-tags

    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 <gitster@pobox.com>
    authored March 04, 2013

Feb 07, 2013

  1. Junio C Hamano

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

    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
    capability.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored January 29, 2013

Oct 26, 2011

  1. Junio C Hamano

    Merge branch 'cn/fetch-prune'

    * 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
    
    Conflicts:
    	remote.c
    authored October 26, 2011

Sep 12, 2011

  1. Junio C Hamano

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

    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 <gitster@pobox.com>
    authored September 09, 2011

Dec 26, 2009

  1. Junio C Hamano

    Merge branch 'sr/vcs-helper'

    * 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
    
    Conflicts:
    	Documentation/git-remote-helpers.txt
    	Makefile
    	builtin-ls-remote.c
    	builtin-push.c
    	transport-helper.c
    authored December 26, 2009

Jun 21, 2009

  1. Junio C Hamano

    Merge branch 'mg/pushurl'

    * 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
    authored June 20, 2009

Jul 03, 2008

  1. Junio C Hamano

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

    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 <gitster@pobox.com>
    authored July 02, 2008

May 25, 2008

  1. Junio C Hamano

    Merge branch 'db/clone-in-c'

    * 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
    
    Conflicts:
    
    	cache.h
    	t/t5700-clone-reference.sh
    authored May 25, 2008

May 23, 2008

  1. Junio C Hamano

    Merge branch 'pb/push'

    * pb/push:
      add special "matching refs" refspec
    authored May 23, 2008

May 09, 2008

  1. Junio C Hamano

    Merge branch 'db/learn-HEAD'

    * db/learn-HEAD:
      Make ls-remote http://... list HEAD, like for git://...
      Make walker.fetch_ref() take a struct ref.
    authored May 08, 2008

Mar 23, 2008

  1. Junio C Hamano

    remote.c: Fix overtight refspec validation

    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 <gitster@pobox.com>
    authored March 20, 2008

Oct 28, 2007

  1. Junio C Hamano

    git-fetch: do not fail when remote branch disappears

    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 <barkalow@iabervon.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored October 26, 2007
Something went wrong with that request. Please try again.