Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes:
> Add a --fetch-prune option to git-fetch, along with fetch.pruneTags
> config option. 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 wanting 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/*$"
I think the last one is supposed to be a regular expression on
existing values. Shouldn't the asterisks be quoted?
Otherwise, it would appears as if "refs/tags:refs/tags///" are
replaced with "refs/tags/*:refs/tags/*", but it certainly is not
what you are doing. I also wonder why the existing one does not
expect a leading '+', which I think is what we place by default
when you clone.
> +-P::
> +--prune-tags::
> + .... This option is
> + merely a shorthand for providing the explicit tag refspec
> + along with `--prune`, see the discussion about that in its
> + documentation.
So would "git fetch -P origin" be like "git fetch --prune --tags
origin"?
> +
> See the PRUNING section below for more details.
>
> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> index 18fac0da2e..5682ed4ae1 100644
> --- a/Documentation/git-fetch.txt
> +++ b/Documentation/git-fetch.txt
> @@ -148,6 +148,30 @@ 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.
>
> +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. 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/*` configured in the refspecs for 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
> +------------------------------------------------
This description is too confusing. First you say "having
... configured in the refspecs for the remote", but configured
refspecs for the remote (I presume that you are missing 'fetch' from
that description and are talking about the "remote.$name.fetch"
configuration variable) are overridden when you give explicit
refspecs from the command line, so the above two are not even
equivalent. The first one gives a refspec explicitly from the
command line, so other configured refspecs like
[remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/*
should be ignored, while the second one, if --prune-tags tells Git
to behave as if
[remote "origin"] fetch = refs/tags/*:refs/tags/*
also exists in the config, would not cause other ones for the same
remote from getting ignored. So...
