Re: git fetch with refspec does not include tags?

Jeff King [off-list ref] 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.

On Thu, Aug 17, 2017 at 12:38:58PM -0700, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

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

quoted

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

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