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
