"Refname 'pull/X/merge' is ambiguous" error on self hosted runner

[SS1823]

Pull Request refs are not handled well with that action on a self hosted runner,
it leaves the refs, and issues error annotations.
For some of my flows these are the only ones, as it hits the message limit on GH actions.

Summary page example:

In the logs:

[mechelewskim]

Hi,
just want to confirm that the issue is still valid on v3:
Download action repository 'actions/checkout@v3' (SHA:93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8)

"C:\Program Files\Git\cmd\git.exe" rev-parse --symbolic-full-name --branches
  Error: error: refname 'pull/36/merge' is ambiguous
  Error: error: refname 'pull/37/merge' is ambiguous

[abbylentz]

Have an open customer ticket from 1e for this issue, https://github.zendesk.com/agent/tickets/1854197

[cory-miller]

From what I can tell there's two issues related here. First, we quickly can fill up the annotations with these error messages. Second, we don't get the full branch list output for anything that is ambiguously name. For example, a tag like refs/tags/v1 and a local branch like refs/heads/tags/v1. Both of these stem from a workaround for Git 2.18 where instead of git branch --list or git rev-parse --symbolic we have to use git rev-parse --symbolic-full-name. I don't know what it would take to drop support for Git 2.18 so we can use a command that doesn't open up potential ambiguous refname messages, but we are at least for now stuck with this. In the interim, we can deal with the first problem using a fix like #1045. I will look to do a release tomorrow with these changes for both v2 and v3.

[cory-miller]

Before doing a release, I want to confirm that a recent release didn't cause any issues in #1049.

[cory-miller]

actions/checkout@v3 or actions/checkout@v3.3.0 can be used to suppress the ambiguous ref errors.