Re: [PATCH 0/2] rebase: handle --update-refs branch symrefs

From: Junio C Hamano <gitster@pobox.com>
Date: May 28, 2026, 20:42 UTC
Message-ID: <xmqqwlwni7vk.fsf@gitster.g>
In-Reply-To: <pull.2126.git.1779946921.gitgitgadget@gmail.com>

"Son Luong Ngoc via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 21 quoted lines

> git rebase --update-refs can fail after the normal rebase path has
> successfully updated the current branch when another local branch is a
> symbolic ref to it.
>
> One practical way to arrive at that setup is a default branch rename from
> master to main. While the migration is in progress, a user may keep
> refs/heads/main as a symbolic ref to refs/heads/master so that both names
> continue to work locally.
>
> If pull.rebase is enabled, a plain git pull can then finish the rebase of
> master and still fail while trying to update the main alias. The reported
> failure looked like this, with line breaks adjusted for the cover letter:
>
> Successfully rebased and updated refs/heads/master.
> error: update_ref failed for ref 'refs/heads/main':
> cannot lock ref 'refs/heads/main':
> is at fc2c7bd5f17abec7861ef759edcd33a1e16662a1
> but expected 531cabdfb49098d6ffa502ed4bf91d1b35edfcfa
> Updated the following refs with --update-refs:
> Failed to update the following refs with --update-refs:
>         refs/heads/main

I vaguely recall we saw a different topic that dealt with a situation somewhat similar to this topic (I think it was about 'describe' giving a name that is not a branch). How would this mesh with what the other topic wanted to do? Instead of filtering out non-branch names (which the other topic did), here we want to filter out names that are not concrete branches but pointers to something else. Would it mean that the logic here is more broad (i.e., both wants to filter out names of non-branches), making the other topic unnecessary?