(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Synchronize change icon does not move when pulling from Command pane (#29944)
• Lock git pull to upstream branch (#44802)

Looks like this is indeed connected to #44802
"git pull origin master" does not pull down tags
"git pull" does.

Just tested this locally by creating a tag on a local repo, and then running both of them:
git pull origin master

From git.internal.company.com:team/testrepo
 * branch            master     -> FETCH_HEAD
Already up-to-date.

git pull

From git.internal.company.com:team/testrepo
 * [new tag]         Testing11  -> Testing11
Already up-to-date.

I checked my understanding on the Git mailing list (message here) and the reply makes it clear that "git pull origin master" will not fetch tags by default.

This is a regression - can we please revert?

Oh that's a sad consequence. Workaround for now is to run Git: Fetch.

Using git pull remote branch is usually the best option because it avoids the weird semantics of what git pull does, since those semantics have changed between versions, so I still prefer we'd use it. I wonder if there's a way to still run git pull remote branch and bring in tags? Otherwise, we can always run git fetch beforehand as well.

"git pull origin master --tags" does it for me.

@andrewducker - me too. I'm using Git version 2.12.2.windows.2.

But, the --tags flag is not documented on my local docs or at https://git-scm.com/docs/git-pull. Which is probably the type fetch/pull consistency between versions that @joaomoreno mentions.

I don't see any documented flags in git pull that will pull tags without invoking fetch though.

Oh nice, I actually searched for it and also failed to see it documented. I'd just add it, what do you guys think?

Ideally the flag is just an omission from the docs, but is available on all platforms. I've only got access to Windows here. @andrewducker is a colleague - he's just asked the git mailing list this point.

I checked with the Git mailing list again and got this response.

Looks like it will work, because "git pull --tags" calls "git fetch" with the "--tags" parameter.

I think it's worth reading the discussion.

And I think that adding "--tags" will fix our use case. Although the people on the Git mailing list seem confused as to why you aren't just using "git pull" as VSCode used to.

@andrewducker I posted that. To clarify I can guess what VSCode might be trying to do here, but am reluctant to give advice about what it should do without some context about why it made the switch.

But it's relevant to point out that --tags has certain pathological behaviors that IDEs may not want. In most repos (if all tags are on "master" anyway) it won't matter, but in some it can be really pathological. I.e. if you have wildly divergent branches or unrelated histories you'll end up pulling in a lot of refs you don't need, and which wouldn't have been fetched when it was just git pull.

@avar The change was made in #44802 - (in case that wasn't entirely clear), where @joaomoreno said that it was to avoid situations like this.

Hopefully having both of you here will make it clear what the correct way forward is :-)

@joaomoreno Any thoughts on the solution here?

I'll just add --tags.

Thanks. Sounds like this is an improvement for minimal cost for most situations. With the odd pathological behaviors @avar situation no worse off than before version 1.22.1 (using just git pull).