Re: Deleting the "current" branch in remote bare repositories

From: Jeff King <peff@peff.net>
Date: Feb 8, 2009, 11:18 UTC
Message-ID: <20090208111838.GD14359@coredump.intra.peff.net>
In-Reply-To: <7v1vu91d00.fsf@gitster.siamese.dyndns.org>

On Sun, Feb 08, 2009 at 01:42:07AM -0800, Junio C Hamano wrote:

Show 9 quoted lines

> 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