Re: Question about 'branch -d' safety

Hi,

I'm sorry to revive this old thread. But I recently hit this
behavior myself, using the workflow described below, and I ended up
deleting an unmerged branch with git branch -d.

This discussion is about v1.7.0-rc0~18^2 (branch -d: base the
"already-merged" safety on the branch it merges with, 2009-12-29),
which teaches 'git branch' to delete a branch with -d, if it is
merged into the branch it is tracking, even if it is not merged
into any local branch.

On Wed, Dec 30, 2009 at 12:12:38PM +0900, Nanako Shiraishi wrote:

Quoting Nicolas Sebrecht [off-list ref]

quoted

But even with it, we would hit some foreign workflow. Think: Bob
directly push to Alice and Alice does the same to Bob. I don't use this
kind of workflow myself but I consider them to be sensible enough to
have our attention.

Here is what I think about your scenario.

Bob directly pushes to Alice and Alice does the same to Bob, both
to their refs/remotes/<other person>/ tracking branches, and
their own local branches fork from the remote tracking branches
that keep track of other person's work. You would still want the
check based on that tracking branch, not based on 'master' that
has no relationship with the branches they are exchanging.

So I had a branch 'topic' in two repositories, neither of which was
in any way authoritative. They were both upstreams to each other.
And the 'topic' branch in each tracked the 'topic' branch in the
other.

At some point, I used branch -d to delete branch 'topic' in one
repo. Later, I did the same in the other. I then realized that
after I do git remote prune origin, the branch will be gone,
without ever having being merged into another branch.

I often use branch -d simply to check if I still forgot something
about this branch, or if it has become redundant. With the above
scenario, I can not rely on branch -d safety any more.

On the other hand, I do think the new behavior is quite useful in
general. Maybe the real solution is a reflog for deleted branch
heads, rather than being too careful about whether or not a branch
can be deleted.

Clemens