Files
git/Documentation/config/remote.adoc
Jeff King c834d1a7ce fetch: only respect followRemoteHEAD with configured refspecs
The new followRemoteHEAD feature is triggered for almost every fetch,
causing us to ask the server about the remote "HEAD" and to consider
updating our local tracking HEAD symref. This patch limits the feature
only to the case when we are fetching a remote using its configured
refspecs (typically into its refs/remotes/ hierarchy). There are two
reasons for this.

One is efficiency. E.g., the fixes in 6c915c3f85 (fetch: do not ask for
HEAD unnecessarily, 2024-12-06) and 20010b8c20 (fetch: avoid ls-refs
only to ask for HEAD symref update, 2025-03-08) were aimed at reducing
the work we do when we would not be able to update HEAD anyway. But they
do not quite cover all cases. The remaining one is:

  git fetch origin refs/heads/foo:refs/remotes/origin/foo

which _sometimes_ can update HEAD, but usually not. And that leads us to
the second point, which is being simple and explainable.

The code for updating the tracking HEAD symref requires both that we
learned which ref the remote HEAD points at, and that the server
advertised that ref to us. But because the v2 protocol narrows the
server's advertisement, the command above would not typically update
HEAD at all, unless it happened to point to the "foo" branch. Or even
weirder, it probably _would_ update if the server is very old and
supports only the v0 protocol, which always gives a full advertisement.

This creates confusing behavior for the user: sometimes we may try to
update HEAD and sometimes not, depending on vague rules.

One option here would be to loosen the update code to accept the remote
HEAD even if the server did not advertise that ref. I think that could
work, but it may also lead to interesting corner cases (e.g., creating a
dangling symref locally, even though the branch is not unborn on the
server, if we happen not to have fetched it).

So let's instead simplify the rules: we'll only consider updating the
tracking HEAD symref when we're doing a full fetch of the remote's
configured refs. This is easy to implement; we can just set a flag at
the moment we realize we're using the configured refspecs.  And we can
drop the special case code added by 6c915c3f85 and 20010b8c20, since
this covers those cases. The existing tests from those commits still
pass.

In t5505, an incidental call to "git fetch <remote> <refspec>" updated
HEAD, which caused us to adjust the test in 3f763ddf28 (fetch: set
remote/HEAD if it does not exist, 2024-11-22). We can now adjust that
back to how it was before the feature was added.

Even though t5505 is incidentally testing our new desired behavior,
we'll add an explicit test in t5510 to make sure it is covered.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-03-18 12:21:25 -07:00

123 lines
5.1 KiB
Plaintext

remote.pushDefault::
The remote to push to by default. Overrides
`branch.<name>.remote` for all branches, and is overridden by
`branch.<name>.pushRemote` for specific branches.
remote.<name>.url::
The URL of a remote repository. See linkgit:git-fetch[1] or
linkgit:git-push[1]. A configured remote can have multiple URLs;
in this case the first is used for fetching, and all are used
for pushing (assuming no `remote.<name>.pushurl` is defined).
Setting this key to the empty string clears the list of urls,
allowing you to override earlier config.
remote.<name>.pushurl::
The push URL of a remote repository. See linkgit:git-push[1].
If a `pushurl` option is present in a configured remote, it
is used for pushing instead of `remote.<name>.url`. A configured
remote can have multiple push URLs; in this case a push goes to
all of them. Setting this key to the empty string clears the
list of urls, allowing you to override earlier config.
remote.<name>.proxy::
For remotes that require curl (http, https and ftp), the URL to
the proxy to use for that remote. Set to the empty string to
disable proxying for that remote.
remote.<name>.proxyAuthMethod::
For remotes that require curl (http, https and ftp), the method to use for
authenticating against the proxy in use (probably set in
`remote.<name>.proxy`). See `http.proxyAuthMethod`.
remote.<name>.fetch::
The default set of "refspec" for linkgit:git-fetch[1]. See
linkgit:git-fetch[1].
remote.<name>.push::
The default set of "refspec" for linkgit:git-push[1]. See
linkgit:git-push[1].
remote.<name>.mirror::
If true, pushing to this remote will automatically behave
as if the `--mirror` option was given on the command line.
remote.<name>.skipDefaultUpdate::
A deprecated synonym to `remote.<name>.skipFetchAll` (if
both are set in the configuration files with different
values, the value of the last occurrence will be used).
remote.<name>.skipFetchAll::
If true, this remote will be skipped when updating
using linkgit:git-fetch[1], the `update` subcommand of
linkgit:git-remote[1], and ignored by the prefetch task
of `git maintenance`.
remote.<name>.receivepack::
The default program to execute on the remote side when pushing. See
option --receive-pack of linkgit:git-push[1].
remote.<name>.uploadpack::
The default program to execute on the remote side when fetching. See
option --upload-pack of linkgit:git-fetch-pack[1].
remote.<name>.tagOpt::
Setting this value to --no-tags disables automatic tag following when
fetching from remote <name>. Setting it to --tags will fetch every
tag from remote <name>, even if they are not reachable from remote
branch heads. Passing these flags directly to linkgit:git-fetch[1] can
override this setting. See options --tags and --no-tags of
linkgit:git-fetch[1].
remote.<name>.vcs::
Setting this to a value <vcs> will cause Git to interact with
the remote with the git-remote-<vcs> helper.
remote.<name>.prune::
When set to true, fetching from this remote by default will also
remove any remote-tracking references that no longer exist on the
remote (as if the `--prune` option was given on the command line).
Overrides `fetch.prune` settings, if any.
remote.<name>.pruneTags::
When set to true, fetching from this remote by default will also
remove any local tags that no longer exist on the remote if pruning
is activated in general via `remote.<name>.prune`, `fetch.prune` or
`--prune`. Overrides `fetch.pruneTags` settings, if any.
+
See also `remote.<name>.prune` and the PRUNING section of
linkgit:git-fetch[1].
remote.<name>.promisor::
When set to true, this remote will be used to fetch promisor
objects.
remote.<name>.partialclonefilter::
The filter that will be applied when fetching from this promisor remote.
Changing or clearing this value will only affect fetches for new commits.
To fetch associated objects for commits already present in the local object
database, use the `--refetch` option of linkgit:git-fetch[1].
remote.<name>.serverOption::
The default set of server options used when fetching from this remote.
These server options can be overridden by the `--server-option=` command
line arguments.
+
This is a multi-valued variable, and an empty value can be used in a higher
priority configuration file (e.g. `.git/config` in a repository) to clear
the values inherited from a lower priority configuration files (e.g.
`$HOME/.gitconfig`).
remote.<name>.followRemoteHEAD::
How linkgit:git-fetch[1] should handle updates to `remotes/<name>/HEAD`
when fetching using the configured refspecs of a remote.
The default value is "create", which will create `remotes/<name>/HEAD`
if it exists on the remote, but not locally; this will not touch an
already existing local reference. Setting it to "warn" will print
a message if the remote has a different value than the local one;
in case there is no local reference, it behaves like "create".
A variant on "warn" is "warn-if-not-$branch", which behaves like
"warn", but if `HEAD` on the remote is `$branch` it will be silent.
Setting it to "always" will silently update `remotes/<name>/HEAD` to
the value on the remote. Finally, setting it to "never" will never
change or create the local reference.