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.