From 3b306ae249f605da4ab5b5e7afa55d5974e92176 Mon Sep 17 00:00:00 2001
From: Wolfgang Müller
Date: Sun, 13 Jun 2021 20:30:21 +0200
Subject: content: Add new post: "Patch workflows and git branch -d"

---
 content/3/index.md | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 content/3/index.md

(limited to 'content')

diff --git a/content/3/index.md b/content/3/index.md
new file mode 100644
index 0000000..8682fe2
--- /dev/null
+++ b/content/3/index.md
@@ -0,0 +1,31 @@
++++
+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`.
-- 
cgit v1.2.3-2-gb3c3