Re: git fetch with refspec does not include tags?

Kevin Daudt [off-list ref] writes:

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

quoted

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:

quoted

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

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

Kevin Daudt [off-list ref] writes:

quoted

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

quoted

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:

quoted

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

On Thu, Aug 17, 2017 at 10:43:12PM +0200, Kevin Daudt wrote:

quoted

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.

Yeah, I don't think we want to go back to the original behavior. I agree
that it is partially to blame for the inconsistency that started this
thread, but I think on balance it has saved much more confusion than it
has started. And we can address that inconsistency with better tag rules
(like the "autofollow if we wrote any real refs" thing).

I don't have a patch for that yet, so if anybody feels like taking a
look, it would be much appreciated.

-Peff

On Sun, Aug 20, 2017 at 03:47:28AM -0400, Jeff King wrote:

Yeah, I don't think we want to go back to the original behavior. I agree
that it is partially to blame for the inconsistency that started this
thread, but I think on balance it has saved much more confusion than it
has started. And we can address that inconsistency with better tag rules
(like the "autofollow if we wrote any real refs" thing).

I don't have a patch for that yet, so if anybody feels like taking a
look, it would be much appreciated.

Also: I don't think we've seen a patch yet for documenting the current
auto-follow behavior.  Even if we don't make a behavior change, let's
not forget to improve that, which should be much less work. :)

-Peff