Bug: `git fetch --prune origin master:refs/foo` incorrectly prunes refs/foo

Bug: `git fetch --prune origin master:refs/foo` incorrectly prunes refs/foo

[Lily Ballard]

When using the --prune flag (or fetch.prune=true), a `git fetch` command that uses a refspec to update a ref that doesn’t exist remotely will behave incorrectly if the ref already exists locally. For example:

> git fetch --prune master:refs/foo

If refs/foo doesn’t exist, this command will create it with the contents of origin’s master. If refs/foo does exist, it will be pruned immediately. If the `git fetch` doesn’t actually fetch anything (because the commits exist locally) then it will exit with success, despite the ref not existing locally. If it does fetch commits, it will fail with a “cannot lock ref” error.

Here’s the flow for fetching twice:

> git fetch --prune origin master:refs/foo
From <url>
 * [new branch]            master     -> refs/foo
> git fetch --prune origin master:refs/foo
From <url>
 - [deleted]               (none)     -> refs/foo
> git rev-parse --verify refs/foo
fatal: Needed a single revision

And here’s what I get if the ref already exists and the fetch actually downloads commits (in this case I’m using --force but that’s not necessary for the bug):

> git fetch --prune --force origin pull/7267/head:refs/foo
From <url>
 - [deleted]               (none)     -> refs/foo
error: cannot lock ref 'refs/foo': unable to resolve reference 'refs/foo'
 ! e090924c71...ca5f06da05 refs/pull/7267/head -> refs/foo  (unable to update local ref)

This was reproduced using git version 2.22.0.

-Lily Ballard