Stefan Haller <lists@xxxxxxxxxxxxxxxx> 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.
