Re: A couple branch questions

[Junio C Hamano <gitster@pobox.com>]

"David Symonds" <dsymonds@gmail.com> 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.".