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

[Junio C Hamano <gitster@pobox.com>]

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.