brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> 于2024年8月30日周五 05:32写道： > > On 2024-08-28 at 23:23:57, Yukai Chou wrote: > > In using `git fetch [<options>] [<repository> [<refspec>…]]`, > > - when a branch is specified as <refspec>, no tags are fetched automatically; > > - when no <refspec>s are specified, tags are fetched automatically. > > Yes, this is expected. Tags are refs, and when you specify no refspec, > you're asking for the default behaviour, which usually involves fetching > tags. According to the doc section CONFIGURED REMOTE-TRACKING BRANCHES [1], when no refspec is specified, remote.<repository>.fetch values are used as the refspecs Then according to doc of <refspec> [2], 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). So the tags are fetched due to the + in the remote.<repository>.fetch values, are they? > For example, if I say, `git fetch origin > refs/heads/main:refs/heads/main`, it would be very unexpected for it to > fetch tags as well; ... . Actually, git fetch --update-head-ok origin refs/heads/main:refs/heads/main does fetch tags "that points into the histories being fetched". This time the refspec is given on the command line, without +. According to the doc of CONFIGURED REMOTE-TRACKING BRANCHES [1], 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. [1] https://git-scm.com/docs/git-fetch#_configured_remote_tracking_branches [2] https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt-ltrefspecgt Yukai
