git-fetch

SYNOPSIS
       git fetch <options> <repository> <refspec>...

       git fetch <options> <group>

       git fetch --multiple <options> [<repository> | <group>]...

       git fetch --all <options>

DESCRIPTION
       Fetches named heads or tags from one or more other repositories, along
       with the objects necessary to complete them.

       The ref names and their object names of fetched refs are stored in
       .git/FETCH_HEAD. This information is left for a later merge operation
       done by git merge.

       When <refspec> stores the fetched result in tracking branches, the tags
       that point at these branches are automatically followed. This is done
       by first fetching from the remote using the given <refspec>s, and if
       the repository has objects that are pointed by remote tags that it does
       not yet have, then fetch those missing tags. If the other end has tags
       that point at branches you are not interested in, you will not get
       them.

       git fetch can fetch from either a single named repository, or or from
       several repositories at once if <group> is given and there is a
       remotes.<group> entry in the configuration file. (See git-config(1)).

OPTIONS
       --all
           Fetch all remotes.

       -a, --append
           Append ref names and object names of fetched refs to the existing
           contents of .git/FETCH_HEAD. Without this option old data in
           .git/FETCH_HEAD will be overwritten.

       --depth=<depth>
           Deepen the history of a shallow repository created by git clone
           with --depth=<depth> option (see git-clone(1)) by the specified
           number of commits.

       --dry-run
           Show what would be done, without making any changes.

       -f, --force
           When git fetch is used with <rbranch>:<lbranch> refspec, it refuses
           to update the local branch <lbranch> unless the remote branch
           <rbranch> it fetches is a descendant of <lbranch>. This option
           overrides that check.

       -k, --keep
           remote repository are fetched and stored locally. This option
           disables this automatic tag following.

       -t, --tags
           Most of the tags are fetched automatically as branch heads are
           downloaded, but tags that do not point at objects reachable from
           the branch heads that are being tracked will not be fetched by this
           mechanism. This flag lets all tags and their associated objects be
           downloaded.

       -u, --update-head-ok
           By default git fetch refuses to update the head which corresponds
           to the current branch. This flag disables the check. This is purely
           for the internal use for git pull to communicate with git fetch,
           and unless you are implementing your own Porcelain you are not
           supposed to use it.

       --upload-pack <upload-pack>
           When given, and the repository to fetch from is handled by git
           fetch-pack, --exec=<upload-pack> is passed to the command to
           specify non-default path for the command run on the other end.

       -q, --quiet
           Pass --quiet to git-fetch-pack and silence any other internally
           used git commands.

       -v, --verbose
           Be verbose.

       <repository>
           The "remote" repository that is the source of a fetch or pull
           operation. This parameter can be either a URL (see the section GIT
           URLS below) or the name of a remote (see the section REMOTES
           below).

       <group>
           A name referring to a list of repositories as the value of
           remotes.<group> in the configuration file. (See git-config(1)).

       <refspec>
           The format of a <refspec> parameter is an optional plus +, followed
           by the source ref <src>, followed by a colon :, followed by the
           destination ref <dst>.

           The remote ref that matches <src> is fetched, and if <dst> is not
           empty string, the local ref that matches it is fast-forwarded using
           <src>. If the optional plus + is used, the local ref is updated
           even if it does not result in a fast-forward update.

               Note
               If the remote branch from which you want to pull is modified in
               non-linear ways such as being rewound and rebased frequently,
               then a pull will attempt a merge with an older version of
               itself, likely conflict, and fail. It is under these conditions
               (i.e.  Pull: B:remote-B), and have a separate branch my-B to do
               your development on top of it. The latter is created by git
               branch my-B remote-B (or its equivalent git checkout -b my-B
               remote-B). Run git fetch to keep track of the progress of the
               remote side, and when you see something new on the remote
               branch, merge it into your development branch with git pull .
               remote-B, while you are on my-B branch.

               Note
               There is a difference between listing multiple <refspec>
               directly on git pull command line and having multiple Pull:
               <refspec> lines for a <repository> and running git pull command
               without any explicit <refspec> parameters. <refspec> listed
               explicitly on the command line are always merged into the
               current branch after fetching. In other words, if you list more
               than one remote refs, you would be making an Octopus. While git
               pull run without any explicit <refspec> parameter takes default
               <refspec>s from Pull: lines, it merges only the first <refspec>
               found into the current branch, after fetching all the remote
               refs. This is because making an Octopus from remote refs is
               rarely done, while keeping track of multiple remote heads in
               one-go by fetching more than one is often useful.
           Some short-cut notations are also supported.

           o    tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>;
               it requests fetching everything up to the given tag.

           o   A parameter <ref> without a colon is equivalent to <ref>: when
               pulling/fetching, so it merges <ref> into the current branch
               without storing the remote branch anywhere locally

GIT URLS
       One of the following notations can be used to name the remote
       repository:

       o   rsync://host.xz/path/to/repo.git/

       o    http://host.xz[:port]/path/to/repo.git/

       o    https://host.xz[:port]/path/to/repo.git/

       o   git://host.xz[:port]/path/to/repo.git/

       o   git://host.xz[:port]/~user/path/to/repo.git/

       o   ssh://[user@]host.xz[:port]/path/to/repo.git/

       o   ssh://[user@]host.xz/path/to/repo.git/

       o   ssh://[user@]host.xz/~user/path/to/repo.git/

       o   ssh://[user@]host.xz/~/path/to/repo.git

       SSH is the default transport protocol over the network. You can
       To sync with a local directory, you can use:

       o   /path/to/repo.git/

       o    file:///path/to/repo.git/

       They are mostly equivalent, except when cloning. See git-clone(1) for
       details.

       If there are a large number of similarly-named remote repositories and
       you want to use a different format for them (such that the URLs you use
       will be rewritten into URLs that work), you can create a configuration
       section of the form:

                   [url "<actual url base>"]
                           insteadOf = <other url base>


       For example, with this:

                   [url "git://git.host.xz/"]
                           insteadOf = host.xz:/path/to/
                           insteadOf = work:


       a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
       rewritten in any context that takes a URL to be
       "git://git.host.xz/repo.git".

       If you want to rewrite URLs for push only, you can create a
       configuration section of the form:

                   [url "<actual url base>"]
                           pushInsteadOf = <other url base>


       For example, with this:

                   [url "ssh://example.org/"]
                           pushInsteadOf = git://example.org/


       a URL like "git://example.org/path/to/repo.git" will be rewritten to
       "ssh://example.org/path/to/repo.git" for pushes, but pulls will still
       use the original URL.

REMOTES
       The name of one of the following can be used instead of a URL as
       <repository> argument:

       o   a remote in the git configuration file: $GIT_DIR/config,

       o   a file in the $GIT_DIR/remotes directory, or


                   [remote "<name>"]
                           url = <url>
                           pushurl = <pushurl>
                           push = <refspec>
                           fetch = <refspec>


       The <pushurl> is used for pushes only. It is optional and defaults to
       <url>.

   Named file in $GIT_DIR/remotes
       You can choose to provide the name of a file in $GIT_DIR/remotes. The
       URL in this file will be used to access the repository. The refspec in
       this file will be used as default when you do not provide a refspec on
       the command line. This file should have the following format:

                   URL: one of the above URL format
                   Push: <refspec>
                   Pull: <refspec>


       Push: lines are used by git push and Pull: lines are used by git pull
       and git fetch. Multiple Push: and Pull: lines may be specified for
       additional branch mappings.

   Named file in $GIT_DIR/branches
       You can choose to provide the name of a file in $GIT_DIR/branches. The
       URL in this file will be used to access the repository. This file
       should have the following format:

                   <url>#<head>


       <url> is required; #<head> is optional.

       Depending on the operation, git will use one of the following refspecs,
       if you don't provide one on the command line. <branch> is the name of
       this file in $GIT_DIR/branches and <head> defaults to master.

       git fetch uses:

                   refs/heads/<head>:refs/heads/<branch>


       git push uses:

                   HEAD:refs/heads/<head>


EXAMPLES
       o   Update the remote-tracking branches:

               $ git fetch origin

           and maint from the remote repository.

           The pu branch will be updated even if it is does not fast-forward,
           because it is prefixed with a plus sign; tmp will not be.

SEE ALSO
       git-pull(1)

AUTHOR
       Written by Linus Torvalds <torvalds@osdl.org[1]> and Junio C Hamano
       <gitster@pobox.com[2]>

DOCUMENTATION
       Documentation by David Greaves, Junio C Hamano and the git-list
       <git@vger.kernel.org[3]>.

GIT
       Part of the git(1) suite

NOTES
        1. torvalds@osdl.org
           mailto:torvalds@osdl.org

        2. gitster@pobox.com
           mailto:gitster@pobox.com

        3. git@vger.kernel.org
           mailto:git@vger.kernel.org



Git 1.7.0.4                       04/12/2010                      GIT-FETCH(1)