{"thread":{"id":"64833","subject":"How to get failed refs with new 'git fetch' behavior?","startedAt":"2026-01-20T06:20:10Z","lastAt":"2026-01-21T05:28:23Z","messageCount":3,"participants":["Stepan Tsymbal","Kristoffer Haugsbakk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"534212","messageId":"CAM8dTE=RciNHyyyhtprjXL22deTrzj5DKcBsSiAt0jFz6Az8JQ@mail.gmail.com","threadId":"64833","inReplyTo":null,"subject":"How to get failed refs with new 'git fetch' behavior?","fromName":"Stepan Tsymbal","fromEmail":"stsymbal@atlassian.com","sentAt":"2026-01-20T06:19:59Z","receivedAt":"2026-01-20T06:20:10Z","isPatch":false,"sender":{"key":"stsymbal@atlassian.com","avatar":null},"body":"Hello everyone,\nAppreciate your time and effort on developing and supporting the tool!\nI hope you can help me understand how to work with new behavior\nintroduced in 2.51.\n\nWe parse output of ‘git fetch’ command in Bitbucket - in automation\nthat synchronizes mirrors. And from the output we see what references\nwere successfully updated and what failed.\n\nIn 0e358de (fetch: use batched reference updates) ‘git fetch’ started\nto use batched reference updates. Which is a great improvement by\nitself, and required the change in 'git fetch' output.\n\nWith git 2.50, when repositories had directory/file ref conflicts, the\nerrors were explicit:\n    $ git fetch\n    error: cannot lock ref 'refs/remotes/origin/branch_path':\n     'refs/remotes/origin/branch_path/conflict' exists; cannot create\n'refs/remotes/origin/branch_path'\n    From /Users/stsymbal/repos/git-conflict-test/first/../first\n     ! [new branch]      branch_path -> origin/branch_path  (unable to\nupdate local ref)\n    error: some local refs could not be updated; try running\n     'git remote prune origin' to remove any old, conflicting branches\n\nAnd git 2.51, in the same situation, no longer tells what ref failed:\n    $ git fetch\n    From /Users/stsymbal/repos/git-conflict-test/first/../first\n     * [new branch]      branch_path -> origin/branch_path\n    error: some local refs could not be updated; try running\n     'git remote prune origin' to remove any old, conflicting branches\n\nIt is trivial in case of a single ref being fetched, but when fetching\nmany refs there is no obvious way to see which one failed. For other\nerrors there will be a single error message per ref, but not for\ndirectory/file conflict.\nThe 'reference-transaction' hook also lists all references as committed.\n\nIs it expected behavior moving forward? Can you suggest any\nworkarounds to know what refs were successful / failed?\n\nReproducible example:\n    mkdir first && cd first\n    git init -b main\n    git commit --allow-empty -m \"initial commit\"\n    git clone ../first ../second\n    git switch -c branch_path\n    git commit --allow-empty -m \"another commit\"\n    cd ../second\n    git update-ref refs/remotes/origin/branch_path/conflict HEAD\n    git fetch\n\nThanks!\n"},{"id":"534213","messageId":"913c7904-1f31-4d76-bb4e-178ab94f0e71@app.fastmail.com","threadId":"64833","inReplyTo":"CAM8dTE=RciNHyyyhtprjXL22deTrzj5DKcBsSiAt0jFz6Az8JQ@mail.gmail.com","subject":"Re: How to get failed refs with new 'git fetch' behavior?","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2026-01-20T08:03:33Z","receivedAt":"2026-01-20T08:03:55Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Tue, Jan 20, 2026, at 07:19, Stepan Tsymbal wrote:\n> Appreciate your time and effort on developing and supporting the tool!\n> I hope you can help me understand how to work with new behavior\n> introduced in 2.51.\n>\n> We parse output of ‘git fetch’ command in Bitbucket - in automation\n> that synchronizes mirrors. And from the output we see what references\n> were successfully updated and what failed.\n>\n> In 0e358de (fetch: use batched reference updates) ‘git fetch’ started\n> to use batched reference updates. Which is a great improvement by\n> itself, and required the change in 'git fetch' output.\n>\n>[snip]\n>\n> Reproducible example:\n>     mkdir first && cd first\n>     git init -b main\n>     git commit --allow-empty -m \"initial commit\"\n>     git clone ../first ../second\n>     git switch -c branch_path\n>     git commit --allow-empty -m \"another commit\"\n>     cd ../second\n>     git update-ref refs/remotes/origin/branch_path/conflict HEAD\n>     git fetch\n\nI think this is fixed by the topic\nkn/ref-batch-output-error-reporting-fix:\n\nhttps://lore.kernel.org/git/20260114-633-regression-lost-diagnostic-message-when-pushing-non-commit-objects-to-refs-heads-v1-6-f5f8b173c501@gmail.com/\n\nThe output when I use Git v2.52.0 on that script:\n\n    ...\n    Unpacking objects: 100% (1/1), 170 bytes | 170.00 KiB/s, done.\n    From <path>\n     * [new branch]      branch_path -> origin/branch_path\n    error: some local refs could not be updated; try running\n     'git remote prune origin' to remove any old, conflicting branches\n\nThis topic is merged to branch ‘seen’ right now (678fb955 (Merge branch\n'dw/config-global-list' into seen, 2026-01-17)). This is the output there:\n\n    ...\n    Unpacking objects: 100% (1/1), 171 bytes | 171.00 KiB/s, done.\n    error: some local refs could not be updated; try running\n     'git remote prune origin' to remove any old, conflicting branches\n    From <path>\n     ! [new branch]      branch_path -> origin/branch_path  (unable to update local ref)\n"},{"id":"534310","messageId":"CAM8dTE==DXQ5Qo_hJ1mZNX05-ZBdVzg7rqLS7fKaWnZs+OTMvQ@mail.gmail.com","threadId":"64833","inReplyTo":"913c7904-1f31-4d76-bb4e-178ab94f0e71@app.fastmail.com","subject":"Re: How to get failed refs with new 'git fetch' behavior?","fromName":"Stepan Tsymbal","fromEmail":"stsymbal@atlassian.com","sentAt":"2026-01-21T05:28:12Z","receivedAt":"2026-01-21T05:28:23Z","isPatch":false,"sender":{"key":"stsymbal@atlassian.com","avatar":null},"body":"Perfect, thank you!\n\n> I think this is fixed by the topic\n> kn/ref-batch-output-error-reporting-fix\n\nYep, looks like display logic was significantly reworked to\naccommodate former behavior.\nI also can confirm that the build from 'seen' branch behaves as per\nyour example, so it should do the trick.\nNot sure if I can help here in any way, will keep an eye on the release\n\nThanks again!\n"}]}