2005-09-08 00:26:23 +00:00
|
|
|
git-fetch(1)
|
|
|
|
============
|
2005-07-16 07:17:42 +00:00
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
2007-01-18 23:53:37 +00:00
|
|
|
git-fetch - Download objects and refs from another repository
|
2005-07-16 07:17:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
2011-07-02 02:38:26 +00:00
|
|
|
[verse]
|
2010-04-10 02:50:19 +00:00
|
|
|
'git fetch' [<options>] [<repository> [<refspec>...]]
|
|
|
|
'git fetch' [<options>] <group>
|
2010-10-08 17:31:17 +00:00
|
|
|
'git fetch' --multiple [<options>] [(<repository> | <group>)...]
|
2010-04-10 02:50:19 +00:00
|
|
|
'git fetch' --all [<options>]
|
2009-11-09 20:09:56 +00:00
|
|
|
|
2005-07-16 07:17:42 +00:00
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
2014-05-29 19:36:47 +00:00
|
|
|
Fetch branches and/or tags (collectively, "refs") from one or more
|
2014-06-02 15:21:47 +00:00
|
|
|
other repositories, along with the objects necessary to complete their
|
|
|
|
histories. Remote-tracking branches are updated (see the description
|
|
|
|
of <refspec> below for ways to control this behavior).
|
2005-07-16 07:17:42 +00:00
|
|
|
|
2014-05-29 19:36:47 +00:00
|
|
|
By default, any tag that points into the histories being fetched is
|
|
|
|
also fetched; the effect is to fetch tags that
|
2013-10-30 05:33:06 +00:00
|
|
|
point at branches that you are interested in. This default behavior
|
2014-05-29 19:36:47 +00:00
|
|
|
can be changed by using the --tags or --no-tags options or by
|
2015-03-11 20:32:45 +00:00
|
|
|
configuring remote.<name>.tagOpt. By using a refspec that fetches tags
|
2014-05-29 19:36:47 +00:00
|
|
|
explicitly, you can fetch tags that do not point into branches you
|
|
|
|
are interested in as well.
|
2007-02-09 23:41:35 +00:00
|
|
|
|
2014-06-02 15:21:47 +00:00
|
|
|
'git fetch' can fetch from either a single named repository or URL,
|
2009-11-09 20:09:56 +00:00
|
|
|
or from several repositories at once if <group> is given and
|
|
|
|
there is a remotes.<group> entry in the configuration file.
|
|
|
|
(See linkgit:git-config[1]).
|
2005-07-16 07:17:42 +00:00
|
|
|
|
2013-12-08 05:56:58 +00:00
|
|
|
When no remote is specified, by default the `origin` remote will be used,
|
|
|
|
unless there's an upstream branch configured for the current branch.
|
|
|
|
|
2014-06-02 15:21:47 +00:00
|
|
|
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 linkgit:git-pull[1].
|
|
|
|
|
2005-07-16 07:17:42 +00:00
|
|
|
OPTIONS
|
|
|
|
-------
|
2005-11-07 05:30:56 +00:00
|
|
|
include::fetch-options.txt[]
|
2005-07-16 07:17:42 +00:00
|
|
|
|
2005-11-07 05:30:56 +00:00
|
|
|
include::pull-fetch-param.txt[]
|
2005-10-20 04:25:39 +00:00
|
|
|
|
2020-08-18 04:01:32 +00:00
|
|
|
--stdin::
|
|
|
|
Read refspecs, one per line, from stdin in addition to those provided
|
|
|
|
as arguments. The "tag <name>" format is not supported.
|
|
|
|
|
2007-07-04 22:21:36 +00:00
|
|
|
include::urls-remotes.txt[]
|
2005-07-16 07:17:42 +00:00
|
|
|
|
2009-10-21 17:21:23 +00:00
|
|
|
|
2014-06-11 14:24:04 +00:00
|
|
|
CONFIGURED REMOTE-TRACKING BRANCHES[[CRTB]]
|
|
|
|
-------------------------------------------
|
2014-05-29 21:24:23 +00:00
|
|
|
|
|
|
|
You often interact with the same remote repository by
|
|
|
|
regularly and repeatedly fetching from it. In order to keep track
|
|
|
|
of the progress of such a remote repository, `git fetch` allows you
|
|
|
|
to configure `remote.<repository>.fetch` configuration variables.
|
|
|
|
|
|
|
|
Typically such a variable may look like this:
|
|
|
|
|
|
|
|
------------------------------------------------
|
|
|
|
[remote "origin"]
|
|
|
|
fetch = +refs/heads/*:refs/remotes/origin/*
|
|
|
|
------------------------------------------------
|
|
|
|
|
|
|
|
This configuration is used in two ways:
|
|
|
|
|
|
|
|
* When `git fetch` is run without specifying what branches
|
|
|
|
and/or tags to fetch on the command line, e.g. `git fetch origin`
|
|
|
|
or `git fetch`, `remote.<repository>.fetch` values are used as
|
2015-10-22 20:02:33 +00:00
|
|
|
the refspecs--they specify which refs to fetch and which local refs
|
2014-05-29 21:24:23 +00:00
|
|
|
to update. The example above will fetch
|
|
|
|
all branches that exist in the `origin` (i.e. any ref that matches
|
|
|
|
the left-hand side of the value, `refs/heads/*`) and update the
|
|
|
|
corresponding remote-tracking branches in the `refs/remotes/origin/*`
|
|
|
|
hierarchy.
|
|
|
|
|
|
|
|
* When `git fetch` is run with explicit branches and/or tags
|
|
|
|
to fetch on the command line, e.g. `git fetch origin master`, the
|
|
|
|
<refspec>s given on the command line determine what are to be
|
|
|
|
fetched (e.g. `master` in the example,
|
|
|
|
which is a short-hand for `master:`, which in turn means
|
|
|
|
"fetch the 'master' branch but I do not explicitly say what
|
|
|
|
remote-tracking branch to update with it from the command line"),
|
|
|
|
and the example command will
|
|
|
|
fetch _only_ the 'master' branch. The `remote.<repository>.fetch`
|
|
|
|
values determine which
|
|
|
|
remote-tracking branch, if any, is updated. When used in this
|
|
|
|
way, the `remote.<repository>.fetch` values do not have any
|
|
|
|
effect in deciding _what_ gets fetched (i.e. the values are not
|
|
|
|
used as refspecs when the command-line lists refspecs); they are
|
|
|
|
only used to decide _where_ the refs that are fetched are stored
|
|
|
|
by acting as a mapping.
|
|
|
|
|
2014-05-29 22:21:31 +00:00
|
|
|
The latter use of the `remote.<repository>.fetch` values can be
|
|
|
|
overridden by giving the `--refmap=<refspec>` parameter(s) on the
|
|
|
|
command line.
|
|
|
|
|
2018-02-09 20:32:11 +00:00
|
|
|
PRUNING
|
|
|
|
-------
|
|
|
|
|
|
|
|
Git has a default disposition of keeping data unless it's explicitly
|
|
|
|
thrown away; this extends to holding onto local references to branches
|
|
|
|
on remotes that have themselves deleted those branches.
|
|
|
|
|
|
|
|
If left to accumulate, these stale references might make performance
|
|
|
|
worse on big and busy repos that have a lot of branch churn, and
|
|
|
|
e.g. make the output of commands like `git branch -a --contains
|
|
|
|
<commit>` needlessly verbose, as well as impacting anything else
|
|
|
|
that'll work with the complete set of known references.
|
|
|
|
|
|
|
|
These remote-tracking references can be deleted as a one-off with
|
|
|
|
either of:
|
|
|
|
|
|
|
|
------------------------------------------------
|
|
|
|
# While fetching
|
|
|
|
$ git fetch --prune <name>
|
|
|
|
|
|
|
|
# Only prune, don't fetch
|
|
|
|
$ git remote prune <name>
|
|
|
|
------------------------------------------------
|
|
|
|
|
|
|
|
To prune references as part of your normal workflow without needing to
|
|
|
|
remember to run that, set `fetch.prune` globally, or
|
|
|
|
`remote.<name>.prune` per-remote in the config. See
|
|
|
|
linkgit:git-config[1].
|
|
|
|
|
|
|
|
Here's where things get tricky and more specific. The pruning feature
|
2021-07-29 11:02:52 +00:00
|
|
|
doesn't actually care about branches, instead it'll prune local <-->
|
2018-02-09 20:32:11 +00:00
|
|
|
remote-references as a function of the refspec of the remote (see
|
|
|
|
`<refspec>` and <<CRTB,CONFIGURED REMOTE-TRACKING BRANCHES>> above).
|
|
|
|
|
|
|
|
Therefore if the refspec for the remote includes
|
|
|
|
e.g. `refs/tags/*:refs/tags/*`, or you manually run e.g. `git fetch
|
|
|
|
--prune <name> "refs/tags/*:refs/tags/*"` it won't be stale remote
|
|
|
|
tracking branches that are deleted, but any local tag that doesn't
|
|
|
|
exist on the remote.
|
|
|
|
|
|
|
|
This might not be what you expect, i.e. you want to prune remote
|
|
|
|
`<name>`, but also explicitly fetch tags from it, so when you fetch
|
|
|
|
from it you delete all your local tags, most of which may not have
|
|
|
|
come from the `<name>` remote in the first place.
|
|
|
|
|
|
|
|
So be careful when using this with a refspec like
|
|
|
|
`refs/tags/*:refs/tags/*`, or any other refspec which might map
|
|
|
|
references from multiple remotes to the same local namespace.
|
|
|
|
|
fetch: add a --prune-tags option and fetch.pruneTags config
Add a --prune-tags option to git-fetch, along with fetch.pruneTags
config option and a -P shorthand (-p is --prune). This allows for
doing any of:
git fetch -p -P
git fetch --prune --prune-tags
git fetch -p -P origin
git fetch --prune --prune-tags origin
Or simply:
git config fetch.prune true &&
git config fetch.pruneTags true &&
git fetch
Instead of the much more verbose:
git fetch --prune origin 'refs/tags/*:refs/tags/*' '+refs/heads/*:refs/remotes/origin/*'
Before this feature it was painful to support the use-case of pulling
from a repo which is having both its branches *and* tags deleted
regularly, and have our local references to reflect upstream.
At work we create deployment tags in the repo for each rollout, and
there's *lots* of those, so they're archived within weeks for
performance reasons.
Without this change it's hard to centrally configure such repos in
/etc/gitconfig (on servers that are only used for working with
them). You need to set fetch.prune=true globally, and then for each
repo:
git -C {} config --replace-all remote.origin.fetch "refs/tags/*:refs/tags/*" "^\+*refs/tags/\*:refs/tags/\*$"
Now I can simply set fetch.pruneTags=true in /etc/gitconfig as well,
and users running "git pull" will automatically get the pruning
semantics I want.
Even though "git remote" has corresponding "prune" and "update
--prune" subcommands I'm intentionally not adding a corresponding
prune-tags or "update --prune --prune-tags" mode to that command.
It's advertised (as noted in my recent "git remote doc: correct
dangerous lies about what prune does") as only modifying remote
tracking references, whereas any --prune-tags option is always going
to modify what from the user's perspective is a local copy of the tag,
since there's no such thing as a remote tracking tag.
Ideally add_prune_tags_to_fetch_refspec() would be something that
would use ALLOC_GROW() to grow the 'fetch` member of the 'remote'
struct. Instead I'm realloc-ing remote->fetch and adding the
tag_refspec to the end.
The reason is that parse_{fetch,push}_refspec which allocate the
refspec (ultimately remote->fetch) struct are called many places that
don't have access to a 'remote' struct. It would be hard to change all
their callsites to be amenable to carry around the bookkeeping
variables required for dynamic allocation.
All the other callers of the API first incrementally construct the
string version of the refspec in remote->fetch_refspec via
add_fetch_refspec(), before finally calling parse_fetch_refspec() via
some variation of remote_get().
It's less of a pain to deal with the one special case that needs to
modify already constructed refspecs than to chase down and change all
the other callsites. The API I'm adding is intentionally not
generalized because if we add more of these we'd probably want to
re-visit how this is done.
See my "Re: [BUG] git remote prune removes local tags, depending on
fetch config" (87po6ahx87.fsf@evledraar.gmail.com;
https://public-inbox.org/git/87po6ahx87.fsf@evledraar.gmail.com/) for
more background info.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-09 20:32:15 +00:00
|
|
|
Since keeping up-to-date with both branches and tags on the remote is
|
|
|
|
a common use-case the `--prune-tags` option can be supplied along with
|
|
|
|
`--prune` to prune local tags that don't exist on the remote, and
|
|
|
|
force-update those tags that differ. Tag pruning can also be enabled
|
|
|
|
with `fetch.pruneTags` or `remote.<name>.pruneTags` in the config. See
|
|
|
|
linkgit:git-config[1].
|
|
|
|
|
|
|
|
The `--prune-tags` option is equivalent to having
|
|
|
|
`refs/tags/*:refs/tags/*` declared in the refspecs of the remote. This
|
|
|
|
can lead to some seemingly strange interactions:
|
|
|
|
|
|
|
|
------------------------------------------------
|
|
|
|
# These both fetch tags
|
|
|
|
$ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
|
|
|
|
$ git fetch --no-tags --prune-tags origin
|
|
|
|
------------------------------------------------
|
|
|
|
|
|
|
|
The reason it doesn't error out when provided without `--prune` or its
|
|
|
|
config versions is for flexibility of the configured versions, and to
|
|
|
|
maintain a 1=1 mapping between what the command line flags do, and
|
|
|
|
what the configuration versions do.
|
|
|
|
|
|
|
|
It's reasonable to e.g. configure `fetch.pruneTags=true` in
|
|
|
|
`~/.gitconfig` to have tags pruned whenever `git fetch --prune` is
|
|
|
|
run, without making every invocation of `git fetch` without `--prune`
|
|
|
|
an error.
|
|
|
|
|
2018-02-09 20:32:16 +00:00
|
|
|
Pruning tags with `--prune-tags` also works when fetching a URL
|
|
|
|
instead of a named remote. These will all prune tags not found on
|
|
|
|
origin:
|
fetch: add a --prune-tags option and fetch.pruneTags config
Add a --prune-tags option to git-fetch, along with fetch.pruneTags
config option and a -P shorthand (-p is --prune). This allows for
doing any of:
git fetch -p -P
git fetch --prune --prune-tags
git fetch -p -P origin
git fetch --prune --prune-tags origin
Or simply:
git config fetch.prune true &&
git config fetch.pruneTags true &&
git fetch
Instead of the much more verbose:
git fetch --prune origin 'refs/tags/*:refs/tags/*' '+refs/heads/*:refs/remotes/origin/*'
Before this feature it was painful to support the use-case of pulling
from a repo which is having both its branches *and* tags deleted
regularly, and have our local references to reflect upstream.
At work we create deployment tags in the repo for each rollout, and
there's *lots* of those, so they're archived within weeks for
performance reasons.
Without this change it's hard to centrally configure such repos in
/etc/gitconfig (on servers that are only used for working with
them). You need to set fetch.prune=true globally, and then for each
repo:
git -C {} config --replace-all remote.origin.fetch "refs/tags/*:refs/tags/*" "^\+*refs/tags/\*:refs/tags/\*$"
Now I can simply set fetch.pruneTags=true in /etc/gitconfig as well,
and users running "git pull" will automatically get the pruning
semantics I want.
Even though "git remote" has corresponding "prune" and "update
--prune" subcommands I'm intentionally not adding a corresponding
prune-tags or "update --prune --prune-tags" mode to that command.
It's advertised (as noted in my recent "git remote doc: correct
dangerous lies about what prune does") as only modifying remote
tracking references, whereas any --prune-tags option is always going
to modify what from the user's perspective is a local copy of the tag,
since there's no such thing as a remote tracking tag.
Ideally add_prune_tags_to_fetch_refspec() would be something that
would use ALLOC_GROW() to grow the 'fetch` member of the 'remote'
struct. Instead I'm realloc-ing remote->fetch and adding the
tag_refspec to the end.
The reason is that parse_{fetch,push}_refspec which allocate the
refspec (ultimately remote->fetch) struct are called many places that
don't have access to a 'remote' struct. It would be hard to change all
their callsites to be amenable to carry around the bookkeeping
variables required for dynamic allocation.
All the other callers of the API first incrementally construct the
string version of the refspec in remote->fetch_refspec via
add_fetch_refspec(), before finally calling parse_fetch_refspec() via
some variation of remote_get().
It's less of a pain to deal with the one special case that needs to
modify already constructed refspecs than to chase down and change all
the other callsites. The API I'm adding is intentionally not
generalized because if we add more of these we'd probably want to
re-visit how this is done.
See my "Re: [BUG] git remote prune removes local tags, depending on
fetch config" (87po6ahx87.fsf@evledraar.gmail.com;
https://public-inbox.org/git/87po6ahx87.fsf@evledraar.gmail.com/) for
more background info.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-09 20:32:15 +00:00
|
|
|
|
|
|
|
------------------------------------------------
|
|
|
|
$ git fetch origin --prune --prune-tags
|
2018-02-09 20:32:16 +00:00
|
|
|
$ git fetch origin --prune 'refs/tags/*:refs/tags/*'
|
|
|
|
$ git fetch <url of origin> --prune --prune-tags
|
|
|
|
$ git fetch <url of origin> --prune 'refs/tags/*:refs/tags/*'
|
fetch: add a --prune-tags option and fetch.pruneTags config
Add a --prune-tags option to git-fetch, along with fetch.pruneTags
config option and a -P shorthand (-p is --prune). This allows for
doing any of:
git fetch -p -P
git fetch --prune --prune-tags
git fetch -p -P origin
git fetch --prune --prune-tags origin
Or simply:
git config fetch.prune true &&
git config fetch.pruneTags true &&
git fetch
Instead of the much more verbose:
git fetch --prune origin 'refs/tags/*:refs/tags/*' '+refs/heads/*:refs/remotes/origin/*'
Before this feature it was painful to support the use-case of pulling
from a repo which is having both its branches *and* tags deleted
regularly, and have our local references to reflect upstream.
At work we create deployment tags in the repo for each rollout, and
there's *lots* of those, so they're archived within weeks for
performance reasons.
Without this change it's hard to centrally configure such repos in
/etc/gitconfig (on servers that are only used for working with
them). You need to set fetch.prune=true globally, and then for each
repo:
git -C {} config --replace-all remote.origin.fetch "refs/tags/*:refs/tags/*" "^\+*refs/tags/\*:refs/tags/\*$"
Now I can simply set fetch.pruneTags=true in /etc/gitconfig as well,
and users running "git pull" will automatically get the pruning
semantics I want.
Even though "git remote" has corresponding "prune" and "update
--prune" subcommands I'm intentionally not adding a corresponding
prune-tags or "update --prune --prune-tags" mode to that command.
It's advertised (as noted in my recent "git remote doc: correct
dangerous lies about what prune does") as only modifying remote
tracking references, whereas any --prune-tags option is always going
to modify what from the user's perspective is a local copy of the tag,
since there's no such thing as a remote tracking tag.
Ideally add_prune_tags_to_fetch_refspec() would be something that
would use ALLOC_GROW() to grow the 'fetch` member of the 'remote'
struct. Instead I'm realloc-ing remote->fetch and adding the
tag_refspec to the end.
The reason is that parse_{fetch,push}_refspec which allocate the
refspec (ultimately remote->fetch) struct are called many places that
don't have access to a 'remote' struct. It would be hard to change all
their callsites to be amenable to carry around the bookkeeping
variables required for dynamic allocation.
All the other callers of the API first incrementally construct the
string version of the refspec in remote->fetch_refspec via
add_fetch_refspec(), before finally calling parse_fetch_refspec() via
some variation of remote_get().
It's less of a pain to deal with the one special case that needs to
modify already constructed refspecs than to chase down and change all
the other callsites. The API I'm adding is intentionally not
generalized because if we add more of these we'd probably want to
re-visit how this is done.
See my "Re: [BUG] git remote prune removes local tags, depending on
fetch config" (87po6ahx87.fsf@evledraar.gmail.com;
https://public-inbox.org/git/87po6ahx87.fsf@evledraar.gmail.com/) for
more background info.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-09 20:32:15 +00:00
|
|
|
------------------------------------------------
|
|
|
|
|
2016-06-26 05:58:06 +00:00
|
|
|
OUTPUT
|
|
|
|
------
|
|
|
|
|
|
|
|
The output of "git fetch" depends on the transport method used; this
|
|
|
|
section describes the output when fetching over the Git protocol
|
|
|
|
(either locally or via ssh) and Smart HTTP protocol.
|
|
|
|
|
|
|
|
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>]
|
|
|
|
-------------------------------
|
|
|
|
|
fetch: introduce machine-parseable "porcelain" output format
The output of git-fetch(1) is obviously designed for consumption by
users, only: we neatly columnize data, we abbreviate reference names, we
print neat arrows and we don't provide information about actual object
IDs that have changed. This makes the output format basically unusable
in the context of scripted invocations of git-fetch(1) that want to
learn about the exact changes that the command performs.
Introduce a new machine-parseable "porcelain" output format that is
supposed to fix this shortcoming. This output format is intended to
provide information about every reference that is about to be updated,
the old object ID that the reference has been pointing to and the new
object ID it will be updated to. Furthermore, the output format provides
the same flags as the human-readable format to indicate basic conditions
for each reference update like whether it was a fast-forward update, a
branch deletion, a rejected update or others.
The output format is quite simple:
```
<flag> <old-object-id> <new-object-id> <local-reference>\n
```
We assume two conditions which are generally true:
- The old and new object IDs have fixed known widths and cannot
contain spaces.
- References cannot contain newlines.
With these assumptions, the output format becomes unambiguously
parseable. Furthermore, given that this output is designed to be
consumed by scripts, the machine-readable data is printed to stdout
instead of stderr like the human-readable output is. This is mostly done
so that other data printed to stderr, like error messages or progress
meters, don't interfere with the parseable data.
A notable ommission here is that the output format does not include the
remote from which a reference was fetched, which might be important
information especially in the context of multi-remote fetches. But as
such a format would require us to print the remote for every single
reference update due to parallelizable fetches it feels wasteful for the
most likely usecase, which is when fetching from a single remote.
In a similar spirit, a second restriction is that this cannot be used
with `--recurse-submodules`. This is because any reference updates would
be ambiguous without also printing the repository in which the update
happens.
Considering that both multi-remote and submodule fetches are user-facing
features, using them in conjunction with `--porcelain` that is intended
for scripting purposes is likely not going to be useful in the majority
of cases. With that in mind these restrictions feel acceptable. If
usecases for either of these come up in the future though it is easy
enough to add a new "porcelain-v2" format that adds this information.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-10 12:34:36 +00:00
|
|
|
When using `--porcelain`, the output format is intended to be
|
|
|
|
machine-parseable. In contrast to the human-readable output formats it
|
|
|
|
thus prints to standard output instead of standard error. Each line is
|
|
|
|
of the form:
|
|
|
|
|
|
|
|
-------------------------------
|
|
|
|
<flag> <old-object-id> <new-object-id> <local-reference>
|
|
|
|
-------------------------------
|
|
|
|
|
2016-06-26 05:58:06 +00:00
|
|
|
The status of up-to-date refs is shown only if the --verbose option is
|
|
|
|
used.
|
|
|
|
|
2016-07-01 16:03:31 +00:00
|
|
|
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/*`.
|
|
|
|
|
2016-06-26 05:58:06 +00:00
|
|
|
flag::
|
|
|
|
A single character indicating the status of the ref:
|
|
|
|
(space);; for a successfully fetched fast-forward;
|
|
|
|
`+`;; for a successful forced update;
|
2016-06-26 05:58:08 +00:00
|
|
|
`-`;; for a successfully pruned ref;
|
|
|
|
`t`;; for a successful tag update;
|
2016-06-26 05:58:06 +00:00
|
|
|
`*`;; for a successfully fetched new ref;
|
|
|
|
`!`;; for a ref that was rejected or failed to update; and
|
|
|
|
`=`;; for a ref that was up to date and did not need fetching.
|
|
|
|
|
|
|
|
summary::
|
|
|
|
For a successfully fetched ref, the summary shows the old and new
|
|
|
|
values of the ref in a form suitable for using as an argument to
|
|
|
|
`git log` (this is `<old>..<new>` in most cases, and
|
|
|
|
`<old>...<new>` for forced non-fast-forward updates).
|
|
|
|
|
|
|
|
from::
|
|
|
|
The name of the remote ref being fetched from, minus its
|
|
|
|
`refs/<type>/` prefix. In the case of deletion, the name of
|
|
|
|
the remote ref is "(none)".
|
|
|
|
|
|
|
|
to::
|
|
|
|
The name of the local ref being updated, minus its
|
|
|
|
`refs/<type>/` prefix.
|
|
|
|
|
|
|
|
reason::
|
|
|
|
A human-readable explanation. In the case of successfully fetched
|
|
|
|
refs, no explanation is needed. For a failed ref, the reason for
|
|
|
|
failure is described.
|
2014-05-29 21:24:23 +00:00
|
|
|
|
2009-10-21 17:21:23 +00:00
|
|
|
EXAMPLES
|
|
|
|
--------
|
|
|
|
|
|
|
|
* Update the remote-tracking branches:
|
|
|
|
+
|
|
|
|
------------------------------------------------
|
|
|
|
$ git fetch origin
|
|
|
|
------------------------------------------------
|
|
|
|
+
|
2023-01-14 01:12:12 +00:00
|
|
|
The above command copies all branches from the remote `refs/heads/`
|
|
|
|
namespace and stores them to the local `refs/remotes/origin/` namespace,
|
|
|
|
unless the `remote.<repository>.fetch` option is used to specify a
|
|
|
|
non-default refspec.
|
2009-10-21 17:21:23 +00:00
|
|
|
|
|
|
|
* Using refspecs explicitly:
|
|
|
|
+
|
|
|
|
------------------------------------------------
|
2020-06-25 12:18:57 +00:00
|
|
|
$ git fetch origin +seen:seen maint:tmp
|
2009-10-21 17:21:23 +00:00
|
|
|
------------------------------------------------
|
|
|
|
+
|
2020-06-25 12:18:57 +00:00
|
|
|
This updates (or creates, as necessary) branches `seen` and `tmp` in
|
2009-10-21 17:21:23 +00:00
|
|
|
the local repository by fetching from the branches (respectively)
|
2020-06-25 12:18:57 +00:00
|
|
|
`seen` and `maint` from the remote repository.
|
2009-10-21 17:21:23 +00:00
|
|
|
+
|
2020-06-25 12:18:57 +00:00
|
|
|
The `seen` branch will be updated even if it does not fast-forward,
|
2009-10-21 17:21:23 +00:00
|
|
|
because it is prefixed with a plus sign; `tmp` will not be.
|
|
|
|
|
2014-06-02 15:21:47 +00:00
|
|
|
* Peek at a remote's branch, without configuring the remote in your local
|
2019-01-22 20:16:35 +00:00
|
|
|
repository:
|
2014-06-02 15:21:47 +00:00
|
|
|
+
|
|
|
|
------------------------------------------------
|
|
|
|
$ git fetch git://git.kernel.org/pub/scm/git/git.git maint
|
|
|
|
$ git log FETCH_HEAD
|
|
|
|
------------------------------------------------
|
|
|
|
+
|
|
|
|
The first command fetches the `maint` branch from the repository at
|
|
|
|
`git://git.kernel.org/pub/scm/git/git.git` and the second command uses
|
|
|
|
`FETCH_HEAD` to examine the branch with linkgit:git-log[1]. The fetched
|
|
|
|
objects will eventually be removed by git's built-in housekeeping (see
|
|
|
|
linkgit:git-gc[1]).
|
2009-10-21 17:21:23 +00:00
|
|
|
|
2016-11-14 18:20:24 +00:00
|
|
|
include::transfer-data-leaks.txt[]
|
|
|
|
|
docs: add CONFIGURATION sections that fuzzy map to built-ins
Add a CONFIGURATION section to the documentation of various built-ins,
for those cases where the relevant config/NAME.txt doesn't map only to
one git-NAME.txt. In particular:
* config/blame.txt: used by git-{blame,annotate}.txt. Since the
git-annotate(1) documentation refers to git-blame(1) don't add a
"CONFIGURATION" section to git-annotate(1), only to git-blame(1).
* config/checkout.txt: maps to both git-checkout.txt and
git-switch.txt (but nothing else).
* config/init.txt: should be included in git-init(1) and
git-clone(1).
* config/column.txt: We should ideally mention the relevant subset of
this in git-{branch,clean,status,tag}.txt, but let's punt on it for
now. We will when we eventually split these sort of files into
e.g. config/column.txt and
config/column/{branch,clean,status,tag}.txt, with the former
including the latter set.
Things that are being left out, and why:
* config/{remote,remotes,credential}.txt: Configuration that affects
how we talk to remote repositories is harder to untangle. We'll need
to include some of this in git-{fetch,remote,push,ls-remote}.txt
etc., but some of those only use a small subset of these
options. Let's leave this for now.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-09-07 08:27:05 +00:00
|
|
|
CONFIGURATION
|
|
|
|
-------------
|
|
|
|
|
|
|
|
include::includes/cmd-config-section-all.txt[]
|
|
|
|
|
|
|
|
include::config/fetch.txt[]
|
|
|
|
|
2011-03-06 22:14:15 +00:00
|
|
|
BUGS
|
|
|
|
----
|
2022-03-08 00:14:32 +00:00
|
|
|
Using --recurse-submodules can only fetch new commits in submodules that are
|
|
|
|
present locally e.g. in `$GIT_DIR/modules/`. If the upstream adds a new
|
|
|
|
submodule, that submodule cannot be fetched until it is cloned e.g. by `git
|
|
|
|
submodule update`. This is expected to be fixed in a future Git version.
|
2011-03-06 22:14:15 +00:00
|
|
|
|
2005-11-05 09:37:00 +00:00
|
|
|
SEE ALSO
|
|
|
|
--------
|
2007-12-29 06:20:38 +00:00
|
|
|
linkgit:git-pull[1]
|
2005-11-05 09:37:00 +00:00
|
|
|
|
2005-07-16 07:17:42 +00:00
|
|
|
GIT
|
|
|
|
---
|
2008-06-06 07:07:32 +00:00
|
|
|
Part of the linkgit:git[1] suite
|