On Sun, Feb 08, 2009 at 01:42:07AM -0800, Junio C Hamano wrote: > I think forbidding the removal of the current branch falls into the same > category as forbidding the updating of the current branch. It is what you > would want to avoid in many workflows, and receive.denyDeleteCurrent that > defaults to refuse may eventually be a good way to do this, but we need a > transition plan for that escape hatch. Most people may not see why they > would want to do such a thing, and many people may perceive that in *their > own* workflow such an operation can only be a mistake, but that is not a > good enough reason to suddenly start forbidding something other people > were allowed to do so far. I thought of that, too, but note that receive.denyDeleteCurrent is about preventing mistakes in a _non-bare_ repo. But deleting the HEAD branch is also annoying in a bare repo (but not _as_ annoying; the real impact is that cloners get a "could not checkout" message, but you don't have the weird index-and-HEAD don't sync issue that non-bare repos get). Should such a safety valve apply to both? -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
