From: Jeff King <peff@peff.net>
Date: Sun, 08 Feb 2009 11:18:39 GMT
Subject: Re: Deleting the "current" branch in remote bare repositories
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:

> 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