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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 7, 2024, 16:59 UTC
Message-ID: <xmqqy143wgao.fsf@gitster.g>
In-Reply-To: <bf6308ce-3914-4b85-a04b-4a9716bac538@haller-berlin.de>

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

Show 14 quoted lines

> 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.