On Mon, Feb 09, 2009 at 01:38:28PM -0800, Junio C Hamano wrote:
> > Should the denyCurrentBranch code be triggering at all on a deletion?
> >
> > That is, if I have:
> >
> > [receive]
> > denyCurrentBranch = refuse
> > denyDeleteCurrent = ignore
> >
> > should such a deletion be refused or allowed?
>
> I think denyCurrentBranch means do not touch the currently checked out
> branch, so 'refuse' there should trump whatever denyDeleteCurrent says as
> long as the repository has a work tree.
I'm not sure "trump" is the right behavior. How would I specify "it is
OK to update this branch, but not to delete it, because I have installed
a hook that deals with the former but not the latter".
It seems like "delete" is a subset of "touch", so I think you probably
want to refuse if _either_ is refuse. Which I think maybe is what you
are saying here:
> Perhaps the logic needs to be restructured to:
>
> if (the push affects the current branch) {
> if (in a repository with a work tree) {
> decide if we want to refuse or allow;
> decide what message to issue;
> }
> if (deletion and we decided not to refuse) {
> decide if we want to refuse or allow;
> decide what message to issue;
> }
> give message(s), possibly with a paragraph break in between;
> if (refuse)
> refuse;
> }
but it was not immediately clear to me.
-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
