Thanks for your quick answer!
> 1. Definitely these defaults are under-documented. I couldn't find
> them anywhere in git-fetch(1).
Yes, some sort of explanation would be good, especially since one of the first sentences state that you always get relevant tags.
> 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".
Personally I think that I would prefer to always fetch relevant tags. If I don't want tags I can simply use the "--no-tags"
-- Magnus
MAGNUS CARLSSON
Staff Software Engineer
ARRIS
o: +46 13 36 75 92
e: magnus.carlsson@xxxxxxxxx
w: www.arris.com
ARRIS: Legal entity: Arris Sweden AB - Registered Office: Teknikringen 2, 583 30 Linkoping, Sweden - Reg No:556518-5831 - VAT No:SE 556518-583
This electronic transmission (and any attached document) is for the sole use of the individual or entity to whom it is addressed. It is confidential and may be attorney-client privileged. In any event the Sender reserves, to the fullest extent, any "legal advice privilege". Any further distribution or copying of this message is strictly prohibited. If you received this message in error, please notify the Sender immediately and destroy the attached message (and all attached documents).
________________________________________
From: Jeff King <peff@xxxxxxxx>
Sent: Thursday, August 17, 2017 11:28
To: Carlsson, Magnus
Cc: git@xxxxxxxxxxxxxxx
Subject: Re: git fetch with refspec does not include tags?
On Thu, Aug 17, 2017 at 09:02:52AM +0000, Carlsson, Magnus wrote:
> In the git fetch documentation it states that by default you will
> fetch all tags that point into the history to the branches fetched.
>
> "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. This default behavior can be changed by using
> the --tags or --no-tags options or by configuring
> remote.<name>.tagOpt. By using a refspec that fetches tags explicitly,
> you can fetch tags that do not point into branches you are interested
> in as well."
>
> But for me I get tags if I do "git fetch" or "git fetch origin" but if
> I do "git fetch origin master" I don't get tags related to the master
> branch.
>
> I understand that this might be due to me specifying a refspec and
> then it will only get that exact refspec, but for me it's not that
> clear from the documentation what I should expect. I read it as when I
> fetch something all related tags will come along.
I'll admit that our tag-autofollow behavior has often confused me. So
I'll try to untangle what's happening at least if not the reasoning. :)
I think the problem is not that you have a refspec, but that your
refspec has no destination. Looking at the fetch code, we seem to turn
on autotags only when the destination is a "real" ref and not just the
default FETCH_HEAD. Which sort-of makes sense. If you're doing a one-off
into FETCH_HEAD, you probably don't want to create tags, even if you
have the objects they point to.
But this is further complicated by the opportunistic tracking-ref
updates. You can see some interesting behavior with a setup like this:
git init parent
git -C parent commit --allow-empty -m one &&
git -C parent tag -m foo mytag
git init child
cd child
git remote add origin ../parent
and then:
# 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
# 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
# and this one does fetch tags, because we have a real destination.
git fetch origin master:foo
So what I'd say is:
1. Definitely these defaults are under-documented. I couldn't find
them anywhere in git-fetch(1).
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".
-Peff
