On Sun, Feb 08, 2009 at 11:05:40AM -0800, Junio C Hamano wrote:
> 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
--
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
