Re: git fetch with refspec does not include tags?
- From
Kevin Daudt <me@ikke.info>
- Date
- Aug 17, 2017, 20:22 UTC
- Message-ID
- <20170817202257.GC3839@alpha.vpn.ikke.info>
- In-Reply-To
- <xmqq1soagf1p.fsf@gitster.mtv.corp.google.com>
On Thu, Aug 17, 2017 at 12:38:58PM -0700, Junio C Hamano wrote:
Show 22 quoted lines
> Jeff King <peff@peff.net> writes:
>
> > # no tags, we just populate FETCH_HEAD because of the bare URL
> > git fetch ../parent
> >
> > # this does fetch tags, because we're storing the result according to
> > # the configured refspec ("refs/heads/*:refs/remotes/origin/*").
> > git fetch origin
>
> The above two look good.
>
> > # this doesn't fetch tags, as the main command is "just" populating
> > # FETCH_HEAD. But then our logic for "hey, we fetched the ref for
> > # refs/remotes/origin/master, so let's update it on the side" kicks
> > # in. And we end up updating FETCH_HEAD _and_ the tracking branch, but
> > # not the tags. Weird.
> > git fetch origin master
>
> Yes, it looks weird, but I suspect that it is probably more correct
> not to fetch tags in this case. I wonder if it would be a solution
> not to do the "on the side" thing---after all the user didn't tell
> us to update refs/remotes/origin/master with this command line.Isn't that how git fetch used to behave, or am I misunderstanding what you mean? It used to be that git fetch <remote> <branch> would not update any remote tracking branches.
From the 1.8.4 release notes:
Show 7 quoted lines
> "git fetch origin master" unlike "git fetch origin" or "git fetch" > did not update "refs/remotes/origin/master"; this was an early > design decision to keep the update of remote tracking branches > predictable, but in practice it turns out that people find it more > convenient to opportunistically update them whenever we have a > chance, and we have been updating them when we run "git push" which > already breaks the original "predictability" anyway.