Jeff King <peff@xxxxxxxx> 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.
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.
