Re: bug related to branches using / in name

[Jeff King <peff@peff.net>]

On Fri, Jun 27, 2008 at 04:31:30PM -0700, Junio C Hamano wrote:

> >> It might be nicer if this were handled automatically, but it would
> >> violate git-fetch's rule about never deleting branches.
> 
> Hmm.  Is there actually such a rule?

I thought so, though I don't necessarily agree with it. But I seem to
recall this being touted as a feature in the past; a remote deleting
some work will not cause it to be deleted locally.

> I was wondering if it might make more sense to do the equivalent of what
> checkout_entry() does (i.e. remove_subtree()) when there is such a

As as long your "equivalent of" means "branch -d"; we need to kill off
both the ref and its reflogs. And therefore...

> conflict.  After all, tracking branches are meant to accept rewinds and
> anything that happens on the remote end, and having to run "git remote
> prune" is not a feature but is a lack of feature in the "git fetch", which
> may make it look like deletion is somewhat special.

The one key difference between rewinds and branch deletion is that the
latter will kill off the reflog, making the history inaccessible. You
can always still access rewound or rebased work via the reflog.

If we don't care about this "safety feature", then I definitely agree
that we should fix the problem rather than hint to the user.

-Peff