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 -- 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
