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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

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

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.

In addition, removing the current branch will affect local operations in
the repository --- the person who were working in the work tree to prepare
for the _next_ commit will now end up creating a root commit.  The effect
is similar, as you correctly point out, to the issue of the HEAD and the
work tree going out of sync that ends up creating a commit with a lot of
reverts.  They both cause the user on the work tree to create an undesired
commit.  Here, the criteria is "does this have a work tree".  I think the
current receive.denyCurrentBranch should also trigger in this case.