NAME¶

SYNOPSIS¶

git fetch [<options>] [<repository> [<refspec>...]]
git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository> | <group>)...]
git fetch --all [<options>]

DESCRIPTION¶

By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the --tags or --no-tags options or by configuring remote.<name>.tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well.

git fetch can fetch from either a single named repository or URL, 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)).

When no remote is specified, by default the origin remote will be used, unless there’s an upstream branch configured for the current branch.

The names of refs that are fetched, together with the object names they point at, are written to .git/FETCH_HEAD. This information may be used by scripts or other git commands, such as git-pull(1).

OPTIONS¶

-a, --append

--depth=<depth>

--deepen=<depth>

--shallow-since=<date>

--shallow-exclude=<revision>

--unshallow

--update-shallow

--dry-run

-f, --force

-k, --keep

--multiple

-p, --prune

-n, --no-tags

--refmap=<refspec>

-t, --tags

--recurse-submodules[=yes|on-demand|no]

-j, --jobs=<n>

--no-recurse-submodules

--submodule-prefix=<path>

--recurse-submodules-default=[yes|on-demand]

-u, --update-head-ok

--upload-pack <upload-pack>

-q, --quiet

-v, --verbose

--progress

-4, --ipv4

-6, --ipv6

<repository>

<group>

<refspec>

GIT URLS¶

Git supports ssh, git, http, and https protocols (in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use it).

The native transport (i.e. git:// URL) does no authentication and should be used with caution on unsecured networks.

The following syntaxes may be used with them:

An alternative scp-like syntax may also be used with the ssh protocol:

This syntax is only recognized if there are no slashes before the first colon. This helps differentiate a local path that contains a colon. For example the local path foo:bar could be specified as an absolute path or ./foo:bar to avoid being misinterpreted as an ssh url.

The ssh and git protocols additionally support ~username expansion:

For local repositories, also supported by Git natively, the following syntaxes may be used:

These two syntaxes are mostly equivalent, except when cloning, when the former implies --local option. See git-clone(1) for details.

When Git doesn’t know how to handle a certain transport protocol, it attempts to use the remote-<transport> remote helper, if one exists. To explicitly request a remote helper, the following syntax may be used:

where <address> may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked. See gitremote-helpers(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¶

All of these also allow you to omit the refspec from the command line because they each contain a refspec which git will use by default.

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

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

        <url>#<head>

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

        HEAD:refs/heads/<head>

CONFIGURED REMOTE-TRACKING BRANCHES¶

Typically such a variable may look like this:

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*

This configuration is used in two ways:

The latter use of the remote.<repository>.fetch values can be overridden by giving the --refmap=<refspec> parameter(s) on the command line.

OUTPUT¶

The status of the fetch is output in tabular form, with each line representing the status of a single ref. Each line is of the form:

 <flag> <summary> <from> -> <to> [<reason>]

The status of up-to-date refs is shown only if the --verbose option is used.

In compact output mode, specified with configuration variable fetch.output, if either entire <from> or <to> is found in the other string, it will be substituted with * in the other string. For example, master -> origin/master becomes master -> origin/*.

flag

summary

from

to

reason

EXAMPLES¶

$ git fetch origin

$ git fetch origin +pu:pu maint:tmp

$ git fetch git://git.kernel.org/pub/scm/git/git.git maint
$ git log FETCH_HEAD

BUGS¶

SEE ALSO¶

GIT¶