Re: git fetch with refspec does not include tags?

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 17, 2017, 19:38 UTC
Message-ID: <xmqq1soagf1p.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170817092853.hteuzni5lxia4ejf@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

>   # 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.

Show 6 quoted lines

>   # 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.

Then not following tags will be in line with all of the above reasoning above.

>   # and this one does fetch tags, because we have a real destination.
>   git fetch origin master:foo

Yup, that is expected.

> So what I'd say is:
>
>   1. Definitely these defaults are under-documented. I couldn't find
>      them anywhere in git-fetch(1).

Yup.

>   2. If we continue to follow the "are we storing any refs" rule for the
>      default, possibly it should expand to "did we store anything,
>      including opportunistic tracking-ref updates".

That also is a workable way to make things consistent.