# How to get failed refs with new 'git fetch' behavior?

3 messages from 2026-01-20 to 2026-01-21. Participants: Stepan Tsymbal, Kristoffer Haugsbakk.
Thread: https://gitlist.dev/t/64833

## Stepan Tsymbal, 2026-01-20 06:19

Subject: How to get failed refs with new 'git fetch' behavior?
Message-ID: <CAM8dTE=RciNHyyyhtprjXL22deTrzj5DKcBsSiAt0jFz6Az8JQ@mail.gmail.com>
URL: https://gitlist.dev/e/CAM8dTE%3DRciNHyyyhtprjXL22deTrzj5DKcBsSiAt0jFz6Az8JQ%40mail.gmail.com

```
Hello everyone,
Appreciate your time and effort on developing and supporting the tool!
I hope you can help me understand how to work with new behavior
introduced in 2.51.

We parse output of ‘git fetch’ command in Bitbucket - in automation
that synchronizes mirrors. And from the output we see what references
were successfully updated and what failed.

In 0e358de (fetch: use batched reference updates) ‘git fetch’ started
to use batched reference updates. Which is a great improvement by
itself, and required the change in 'git fetch' output.

With git 2.50, when repositories had directory/file ref conflicts, the
errors were explicit:
    $ git fetch
    error: cannot lock ref 'refs/remotes/origin/branch_path':
     'refs/remotes/origin/branch_path/conflict' exists; cannot create
'refs/remotes/origin/branch_path'
    From /Users/stsymbal/repos/git-conflict-test/first/../first
     ! [new branch]      branch_path -> origin/branch_path  (unable to
update local ref)
    error: some local refs could not be updated; try running
     'git remote prune origin' to remove any old, conflicting branches

And git 2.51, in the same situation, no longer tells what ref failed:
    $ git fetch
    From /Users/stsymbal/repos/git-conflict-test/first/../first
     * [new branch]      branch_path -> origin/branch_path
    error: some local refs could not be updated; try running
     'git remote prune origin' to remove any old, conflicting branches

It is trivial in case of a single ref being fetched, but when fetching
many refs there is no obvious way to see which one failed. For other
errors there will be a single error message per ref, but not for
directory/file conflict.
The 'reference-transaction' hook also lists all references as committed.

Is it expected behavior moving forward? Can you suggest any
workarounds to know what refs were successful / failed?

Reproducible example:
    mkdir first && cd first
    git init -b main
    git commit --allow-empty -m "initial commit"
    git clone ../first ../second
    git switch -c branch_path
    git commit --allow-empty -m "another commit"
    cd ../second
    git update-ref refs/remotes/origin/branch_path/conflict HEAD
    git fetch

Thanks!

```

## Kristoffer Haugsbakk, 2026-01-20 08:03

Subject: Re: How to get failed refs with new 'git fetch' behavior?
Message-ID: <913c7904-1f31-4d76-bb4e-178ab94f0e71@app.fastmail.com>
URL: https://gitlist.dev/e/913c7904-1f31-4d76-bb4e-178ab94f0e71%40app.fastmail.com
In-Reply-To: <CAM8dTE=RciNHyyyhtprjXL22deTrzj5DKcBsSiAt0jFz6Az8JQ@mail.gmail.com>

```
On Tue, Jan 20, 2026, at 07:19, Stepan Tsymbal wrote:
> Appreciate your time and effort on developing and supporting the tool!
> I hope you can help me understand how to work with new behavior
> introduced in 2.51.
>
> We parse output of ‘git fetch’ command in Bitbucket - in automation
> that synchronizes mirrors. And from the output we see what references
> were successfully updated and what failed.
>
> In 0e358de (fetch: use batched reference updates) ‘git fetch’ started
> to use batched reference updates. Which is a great improvement by
> itself, and required the change in 'git fetch' output.
>
>[snip]
>
> Reproducible example:
>     mkdir first && cd first
>     git init -b main
>     git commit --allow-empty -m "initial commit"
>     git clone ../first ../second
>     git switch -c branch_path
>     git commit --allow-empty -m "another commit"
>     cd ../second
>     git update-ref refs/remotes/origin/branch_path/conflict HEAD
>     git fetch

I think this is fixed by the topic
kn/ref-batch-output-error-reporting-fix:

https://lore.kernel.org/git/20260114-633-regression-lost-diagnostic-message-when-pushing-non-commit-objects-to-refs-heads-v1-6-f5f8b173c501@gmail.com/

The output when I use Git v2.52.0 on that script:

    ...
    Unpacking objects: 100% (1/1), 170 bytes | 170.00 KiB/s, done.
    From <path>
     * [new branch]      branch_path -> origin/branch_path
    error: some local refs could not be updated; try running
     'git remote prune origin' to remove any old, conflicting branches

This topic is merged to branch ‘seen’ right now (678fb955 (Merge branch
'dw/config-global-list' into seen, 2026-01-17)). This is the output there:

    ...
    Unpacking objects: 100% (1/1), 171 bytes | 171.00 KiB/s, done.
    error: some local refs could not be updated; try running
     'git remote prune origin' to remove any old, conflicting branches
    From <path>
     ! [new branch]      branch_path -> origin/branch_path  (unable to update local ref)

```

## Stepan Tsymbal, 2026-01-21 05:28

Subject: Re: How to get failed refs with new 'git fetch' behavior?
Message-ID: <CAM8dTE==DXQ5Qo_hJ1mZNX05-ZBdVzg7rqLS7fKaWnZs+OTMvQ@mail.gmail.com>
URL: https://gitlist.dev/e/CAM8dTE%3D%3DDXQ5Qo_hJ1mZNX05-ZBdVzg7rqLS7fKaWnZs%2BOTMvQ%40mail.gmail.com
In-Reply-To: <913c7904-1f31-4d76-bb4e-178ab94f0e71@app.fastmail.com>

```
Perfect, thank you!

> I think this is fixed by the topic
> kn/ref-batch-output-error-reporting-fix

Yep, looks like display logic was significantly reworked to
accommodate former behavior.
I also can confirm that the build from 'seen' branch behaves as per
your example, so it should do the trick.
Not sure if I can help here in any way, will keep an eye on the release

Thanks again!

```