+++
date = 2021-06-13T20:22:51+02:00
title = "Patch workflows and git branch -d"

[taxonomies]
tags = ["git", "TIL"]
+++

The notion of a "merged" branch is highly dependent on the
[workflow](https://git-scm.com/docs/gitworkflows) 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](https://github.com/git/git/blob/211eca0895794362184da2be2a2d812d070719d3/builtin/branch.c#L116-L121)
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)`](https://git-scm.com/docs/git-cherry). Then you can safely
force deletion of the branch with `git branch -D`