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

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!

On Tue, Jan 20, 2026, at 07:19, Stepan Tsymbal wrote:

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)

Perfect, thank you!

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!