Thoughts on the "branch <b> is not fully merged" error of "git-branch -d"

Thoughts on the "branch <b> is not fully merged" error of "git-branch -d"

[Stefan Haller]

I frequently get this error when trying to delete a branch that was
merged on github, and the remote branch was deleted through github's UI too.

When I then fetch and see that "git branch -v" shows it as "[gone]"), I
will want to delete it, but at that time it is pretty random which
branch I happen to have checked out. If it's some other unrelated branch
that I didn't rebase onto origin/main yet, or if it is main but I didn't
pull yet, then I get the error; but if I'm on main and I have pulled, or
I'm on an unrelated branch and I have rebased onto origin/main, then I
don't.

This feels arbitrary to me. It would seem more useful to me if the error
only appeared if the branch is not contained in any of my local or
remote branches, because only then do I lose commits. Any thoughts on that?

-Stefan

Re: Thoughts on the "branch <b> is not fully merged" error of "git-branch -d"

[Junio C Hamano]

Stefan Haller <lists@haller-berlin.de> writes:

> I frequently get this error when trying to delete a branch that was
> merged on github, and the remote branch was deleted through github's UI too.
>
> When I then fetch and see that "git branch -v" shows it as "[gone]"), I
> will want to delete it, but at that time it is pretty random which
> branch I happen to have checked out. If it's some other unrelated branch
> that I didn't rebase onto origin/main yet, or if it is main but I didn't
> pull yet, then I get the error; but if I'm on main and I have pulled, or
> I'm on an unrelated branch and I have rebased onto origin/main, then I
> don't.
>
> This feels arbitrary to me. It would seem more useful to me if the error
> only appeared if the branch is not contained in any of my local or
> remote branches, because only then do I lose commits. Any thoughts on that?

I think we check against the @{upstream} as well as HEAD these days.
The very original design was geared towards folks who do

    $ git checkout integration-branch
    $ git merge topic
    $ git branch -d topic

and that was why HEAD is a sensible thing to use as a reference
point.  What makes the choice _appear_ arbitrary is your being on a
random unrelated branch when you think of using "branch -d" ;-)

"merged to any other branch" is an absolute no-no.  Imagine that I
have a branch A, and then tentatively build a wip branch B that I am
less sure about than branch A on top:

    ---o---o---a---a   A
                    \
                     b---b---b   B

The reason why I said "tentatively" is because I fully intend to
rebase B (these three 'b' commits) on top of an updated A after I
polish branch A.

                           b'--b'--b' B
                          /
                     a---a   A
                    /
    ---o---o---a---a   (old)A
                    \
                     b---b---b   (old)B

The tip of branch A deserves the same protection as the tip of
branch B from "git branch -d", until the whole thing is integrated.
Granted, you may find A's tip from "git log B", but that should not
be a reason to allow a mistaken "git branch -d A" merely because I
happen to have started exploring another idea that may not work at
all on branch B.

Having said all that, I do not mind if somebody wanted to further
extend builtin/branch.c:branch_merged() so that users can explicitly
configure a set of reference branches.  "The 'master' and 'maint'
are the integration branches that are used in this repository.
Unless the history of a local branch is fully merged to one of
these, 'git branch -d' of such a local branch will stop." may be a
reasonable thing to do.

Thanks.

Re: Thoughts on the "branch <b> is not fully merged" error of "git-branch -d"

[Junio C Hamano]

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

> Having said all that, I do not mind if somebody wanted to further
> extend builtin/branch.c:branch_merged() so that users can explicitly
> configure a set of reference branches.  "The 'master' and 'maint'
> are the integration branches that are used in this repository.
> Unless the history of a local branch is fully merged to one of
> these, 'git branch -d' of such a local branch will stop." may be a
> reasonable thing to do.

If anybody is interested in doing this, I think the design should
also make sure these branches that are designated as reference
branches are protected from 'git branch -d'.

Re: Thoughts on the "branch <b> is not fully merged" error of "git-branch -d"

[Stefan Haller]

On 07.09.24 18:59, Junio C Hamano wrote:
> Stefan Haller <lists@haller-berlin.de> writes:
> 
>> I frequently get this error when trying to delete a branch that was
>> merged on github, and the remote branch was deleted through github's UI too.
>>
>> When I then fetch and see that "git branch -v" shows it as "[gone]"), I
>> will want to delete it, but at that time it is pretty random which
>> branch I happen to have checked out. If it's some other unrelated branch
>> that I didn't rebase onto origin/main yet, or if it is main but I didn't
>> pull yet, then I get the error; but if I'm on main and I have pulled, or
>> I'm on an unrelated branch and I have rebased onto origin/main, then I
>> don't.
>>
>> This feels arbitrary to me. It would seem more useful to me if the error
>> only appeared if the branch is not contained in any of my local or
>> remote branches, because only then do I lose commits. Any thoughts on that?
> 
> I think we check against the @{upstream} as well as HEAD these days.

Yes I know, but in the example I gave, upstream is already gone (maybe I
should have added that I have fetch.prune set to true, that's why).

> Having said all that, I do not mind if somebody wanted to further
> extend builtin/branch.c:branch_merged() so that users can explicitly
> configure a set of reference branches.  "The 'master' and 'maint'
> are the integration branches that are used in this repository.
> Unless the history of a local branch is fully merged to one of
> these, 'git branch -d' of such a local branch will stop." may be a
> reasonable thing to do.

This makes sense to me (if you include the upstreams of master and maint
in that logic, because the local ones might not be up to date).

I should have added that I'm looking at all this from the perspective of
lazygit, again. Currently, lazygit tries "git branch -d" first, and if
that errors (yes, it parses the error output, gasp), it prompts the user
and then uses "git branch -D" if they said yes. Since lazygit already
has a config for what the main branches are, I'll probably change this
logic to do the check on our side, prompt the user if necessary, and use
-D right away.

Thanks for the input!

-Stefan

Re: Thoughts on the "branch <b> is not fully merged" error of "git-branch -d"

[Junio C Hamano]

Stefan Haller <lists@haller-berlin.de> writes:

>> Having said all that, I do not mind if somebody wanted to further
>> extend builtin/branch.c:branch_merged() so that users can explicitly
>> configure a set of reference branches.  "The 'master' and 'maint'
>> are the integration branches that are used in this repository.
>> Unless the history of a local branch is fully merged to one of
>> these, 'git branch -d' of such a local branch will stop." may be a
>> reasonable thing to do.
>
> This makes sense to me (if you include the upstreams of master and maint
> in that logic, because the local ones might not be up to date).

I get the idea behind that statement, but I do not think it is
necessary to make Git second guess the end user is warranted in this
case.

If refs/heads/master builds on top of refs/remotes/origin/master,
and if the user is worried about the former being not up to date
relative to the latter, then the user can say "'branch -d' is safe
if the commit is merged in refs/remotes/origin/master", instead of
telling the command to check with 'refs/heads/master'.

Re: Thoughts on the "branch <b> is not fully merged" error of "git-branch -d"

[Stefan Haller]

On 07.09.24 22:00, Junio C Hamano wrote:
> Stefan Haller <lists@haller-berlin.de> writes:
> 
>>> Having said all that, I do not mind if somebody wanted to further
>>> extend builtin/branch.c:branch_merged() so that users can explicitly
>>> configure a set of reference branches.  "The 'master' and 'maint'
>>> are the integration branches that are used in this repository.
>>> Unless the history of a local branch is fully merged to one of
>>> these, 'git branch -d' of such a local branch will stop." may be a
>>> reasonable thing to do.
>>
>> This makes sense to me (if you include the upstreams of master and maint
>> in that logic, because the local ones might not be up to date).
> 
> I get the idea behind that statement, but I do not think it is
> necessary to make Git second guess the end user is warranted in this
> case.
> 
> If refs/heads/master builds on top of refs/remotes/origin/master,
> and if the user is worried about the former being not up to date
> relative to the latter, then the user can say "'branch -d' is safe
> if the commit is merged in refs/remotes/origin/master", instead of
> telling the command to check with 'refs/heads/master'.

Ah sure, if that configuration takes full refs, then yes, let the user
configure exactly what they want. I thought it would take just bare
branch names. (That's what we do in lazygit, we find this more
convenient. It does take some heuristics to see which of these actually
exist, and whether to use the upstream or local one, but it makes it
easier for users. I'm not proposing to go this way with git.)

-Stefan