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

Reply via email to