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

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

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

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.

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

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

On 07.09.24 18:59, Junio C Hamano wrote:

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

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

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

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

On 07.09.24 22:00, Junio C Hamano wrote:

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