Re: [PATCH v2] branch: report active bisect run when rejecting delete

[Toon Claes <toon@iotcl.com>]

Junio C Hamano <gitster@pobox.com> writes:

> René Scharfe <l.s.r@web.de> writes:
>
>> git branch refuses to delete branches that are currently checked out
>> with a message like this: "error: cannot delete branch 'foo' used by
>> worktree at '/path/of/worktree'".  This can be confusing if it's an
>> internal checkout for git bisect.  Report a more specific error in
>> that case to help users that might have forgotten their bisect run.
>>
>> Suggested-by: stsp <stsp2@yandex.ru>
>> Signed-off-by: René Scharfe <l.s.r@web.de>
>> ---
>> Changes since v2:
>> - Only report bisect runs as specific rejection reason for now.

Works for me.

>> - Leave rebasing unaddressed because I don't see how to formulate
>>   clear and readable messages for those scenarios, yet.
>> - Collect all checkout reasons of all branches in a simple array for
>>   easy use, e.g. to eventually address rebases or for git status.

That's handy for future use.

>> - Rebased onto the landed test_grep conversion.
>
> The scope of this patch has shrunk a bit.  While the 'in use by a
> rebase' state is still recognized internally, unlike in the previous
> round, we guard users only against the 'in use by a bisect' state and
> the 'in use by being checked out' state.
>
> This is probably a good single step, so unless there are objections,
> let's mark the topic for 'next'.

Yeah, I agree it's a step in the right direction.

I've reviewed the patch and looks good to me.

To answer your other question:

> This reminds me of another recent discussion on rewriting a branch
> that is checked out elsewhere, where the "git history" command
> forgot to apply the same safety check:
> 
> https://lore.kernel.org/git/e7dbcede-4486-459c-aa64-e44690e01fe0@gmail.com/
> 
> We definitely need an easy-to-use API to determine consistently
> which branches are in use, and to teach all commands that repoint
> branch tips to use it to offer the same safety to users.  The
> framework that this patch introduces might be a good starting point
> for that effort.

Yeah, there is definetly some overlap here. As far as I can tell this is
a good step in the direction of an API the git-history(1) can use.

-- 
Cheers,
Toon