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