On Thu, Aug 17, 2017 at 01:38:36PM -0700, Junio C Hamano wrote:
> Kevin Daudt <me@xxxxxxxxx> writes:
>
> > On Thu, Aug 17, 2017 at 12:38:58PM -0700, Junio C Hamano wrote:
> >> 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.
> >
> > 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.
>
> No, you are not misunderstanding anything. The "pretend that we
> immediately turned around and fetched" done by "git push" was
> already breaking the predictability, but the change in 1.8.4 made it
> even worse. I am saying that going back to the old behaviour may be
> one option to address the issue being discussed in this thread.
>
Ok. The reason I'm bring this up is because we often had to tell users
in the irc channel that git fetch <remote> <branch> did not update the
remote tracking branches, which confused them, so reverting back might
reintroduce this confusion again.
