"David Symonds" <dsymonds@xxxxxxxxx> writes: > If I have four branches, a, b1, b2 and c, and I've merged b2 into c > (but planning to keep developing on b2), and just merged b1 into a > (which I have checked out), then I probably only want to delete b1, > not b2. The "current" branch is a useful notion because it > significantly simplifies merging/rebasing operations. Not just "simplifies", but it tends to make it much safer. People often mistake that the safety of "branch -d" is to not lose the commit (i.e. not making it unreachable), but that is not the case. That safety already exists in HEAD reflogs. The "branch -d" safety is about not losing the particular point. The information we really are trying to protect is "this branch points at _that commit_", which is just as important if not more. And immediately after merging that branch into your current branch is where we can be fairly certain that you are truly done with the branch and that did not make a typo, if we hear you say "I do not need that branch anymore, delete it". "If it is merged in _some random branch_" does not give such an assurance and an inappropriate test for this purpose. I should point out that the current protection based on HEAD predates the invention of the "branch --track". If we were designing the safety today, it would have taken the form of "if the branch to be removed is fully merged in the branch that it used to be tracking, or the current branch, then it is safe to remove it.". - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
