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

From: Jeff King <peff@peff.net>
Date: Feb 9, 2009, 18:28 UTC
Message-ID: <20090209182843.GA27109@coredump.intra.peff.net>
In-Reply-To: <7v8wogzr3v.fsf@gitster.siamese.dyndns.org>

On Sun, Feb 08, 2009 at 11:05:40AM -0800, Junio C Hamano wrote:

Show 6 quoted lines

> If you remove the current branch from a repository, the impact that
> operation causes the remote users of the repository would be the same
> whether the repository has or does not have a work tree.  And in that
> sense, I think it should apply equally.  The criteria is not "is it bare",
> but "is it used by people remotely".  IOW, you refuse deletion of the
> current branch if other people may fetch from it.

Here are two reasons why we might not want to conflate the two safety valves:

 1. I'm concerned about it becoming more confusing for end users. Right
    now we don't even bother to look at denyCurrentBranch if we are in a
    bare repo. That is, it is easily explained as "this prevents a
    dangerous operation pushing into a non-bare repo, and if you have a
    bare repo, you don't have to care about or set this at all." But
    having it cover HEAD deletion, too, means that it is now "prevent
    some dangerous operations; some things are dangerous if your repo is
    non-bare, but safe otherwise.  But some of the operations are
    dangerous all the time".

    But maybe that is not really a concern. Most users should leave it
    set to the default unless they are clueful enough to know which
    operations are safe and which are not.

 2. It may not be fine-grained enough. If I am a clueful user with a
    post-receive hook, then I may want to set receive.denyCurrentBranch
    to "ignore". But that doesn't necessarily mean my hook gracefully
    handles _deletion_ of the branch. I may want to keep that set to
    "refuse", since it makes no sense for my workflow.

    Such a user is better served by a separate receive.denyDeleteHEAD
    option.

-Peff