> 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. > <refspec> > [...] Since > Git version 2.20, fetching to update `refs/tags/*` works the same way > as when pushing. I.e. any updates will be rejected without `+` in the > refspec (or `--force`). > CONFIGURED REMOTE-TRACKING BRANCHES > [...] > 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 > the refspecs ... > > * 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 (...). The `remote.<repository>.fetch` values determine > which remote-tracking branch, if any, is updated. Steps to reproduce ```shell # prepare a local upstream and fork it git init local-upstream && cd local-upstream for i in 1 2 3; do git commit --allow-empty -m "commit $i"; done git tag v0.3 cd .. git clone file://$(pwd)/local-upstream local-fork # now local-fork has all three commits and a tag v0.3 # add more commits and a new tag to upstream cd local-upstream for i in 4 5; do git commit --allow-empty -m "commit $i"; done git tag v0.5 cd .. # try to fetch new commits and the new tag v0.5 cd local-fork # this fetches commits only git fetch origin main # this finally fetches the tag new v0.5, but why? git fetch origin cd .. ``` [1] https://git-scm.com/docs/git-fetch/2.46.0 Yukai
