blob: 8682fe27b2a3736947e015f416bb22ce76dc69a5 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
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`.
|
