Re: [PATCH 3/6] receive-pack: receive.denyDeleteCurrent

From: Jeff King <peff@peff.net>
Date: Feb 10, 2009, 12:07 UTC
Message-ID: <20090210120753.GB15491@coredump.intra.peff.net>
In-Reply-To: <7veiy7thnv.fsf@gitster.siamese.dyndns.org>

On Mon, Feb 09, 2009 at 01:38:28PM -0800, Junio C Hamano wrote:

Show 13 quoted lines

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

Show 15 quoted lines

> 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