The notion of a “merged” branch is highly dependent on the
workflow used for a project. I was
wanting to clean up some topic branches in my copy of git.git today, but git branch -d refused to delete them, pointing out that they were not yet merged.
I knew for a fact that they were, which made me look up how git branch -d
actually determines that. The manual is not entirely clear, but a
comment
in the code pointed out that git constructs the merge base of the branch and its
upstream (or HEAD if there is none) and checks whether the branch is reachable
from that merge base.
In a patch workflow, this will generally not be true. A lot of things may happen to your patches before inclusion, and with git.git they will get at least one other sign-off. They’ll be recorded in a merge commit, but it will not have your original branch as one of its parents.
Therefore, neither git branch -d nor git branch --merged will report your
branch as merged. Both of these tools are built for the merge workflow instead.
To see if your work was merged in patch-based workflows, use
git-cherry(1). Then you can safely
force deletion of the branch with git branch -D