Re: [PATCH] branch: report kind of checkout when rejecting delete

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Jul 19, 2026, 09:50 UTC
Message-ID: <03a332e0-afaa-4562-a503-2ff8a8f9f2ac@gmail.com>
In-Reply-To: <xmqqa4roq7a8.fsf@gitster.g>

On 18/07/2026 23:09, Junio C Hamano wrote:

Show 14 quoted lines

> René Scharfe <l.s.r@web.de> writes:
> 
>>>> +				switch (kind) {
>>>> +				case BRANCH_CHECKOUT_KIND_CHECKOUT:
>>>> +					error(_("cannot delete branch '%s' "
>>>> +						"used by worktree at '%s'"),
>>>> +					      bname.buf, path);
>>>> +					break;
>>>
>>> We may want to be more explicit and say "cannot delete
>>> branch 'frotz' checked out in worktree at '/tmp/nitfol'"
>>> instead.  Unless this is a catch-all entry for states that
>>> are neither 'rebase', 'bisect', nor 'rebase-merges' but are
>>> somehow otherwise in use, that is.

That's a great suggestion, I don't think there are any other cases so it should be fine to say "checked out".

Show 21 quoted lines

>>>> +				case BRANCH_CHECKOUT_KIND_UPDATE_REF:
>>>> +					error(_("cannot delete branch '%s' "
>>>> +						"used by worktree at '%s' "
>>>> +						"for update-ref"),
>>>> +					      bname.buf, path);
>>>> +					break;
>>>
>>> I was quite lost when searching for cases where this 'update-ref'
>>> state might be encountered, and I still lack confidence.  Can
>>> we make the diagnostic message a bit friendlier to our users?
>>>
>>> For instance, something like: 'You are rebasing a history with
>>> merges in that other worktree, and the tip of this branch will
>>> be updated when that process completes, so you cannot delete
>>> it from here.'  (Naturally, I may have misidentified the exact
>>> nature of the error, but this illustrates the level of detail and
>>> user-facing clarity I hope to see.)
>>
>> That's quite long.  Would it make sense to throw that update-ref
>> case into the rebase bin, i.e. only distinguish between checkout,
>> bisect and rebase?

I also wondered whether we should fold this into the rebase case. My concern is that if the user sees

     cannot delete branch 'feature' because it is being rebased in the
     worktree '../feature'

and then they do

     cd ../feature
     git status

they'll see a different branch name in the status output which is confusing. So I think we either need to improve the status output to show all the branches that are being rewritten (which to my mind is the better option, it is more work but shouldn't be too difficult as it already parses "rebase-merge/git-rebase-todo" and "rebase-merge/done"), or say something like

     cannot delete branch 'feature' because it is being updated by a
     rebase running in '../feature' which is updating multiple branches.

for the update-refs case.

Thanks for working on this, it is a nice usability improvement.

Phillip

Show 8 quoted lines

> Shortening a quite long expression down to digestable pieces is left
> as an exercise for those with this particular itch to scratch ;-).
> I do not personally mind if it ends up indistinguishable from other
> "rebase" case (or unified the "kind" enum into one), but others may
> have ideas to shorten the message to fit in the pattern we see
> above.
> 
> Thanks.