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

quoted text
> >> 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.

quoted text
> 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...

quoted text
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html