Re: [PATCH] Documentation/config.txt: denyDeleteCurrent applies to bare repos too

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 17, 2013, 22:23 UTC
Message-ID: <xmqq4n8fy1t3.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1381886818-14337-1-git-send-email-bcasey@nvidia.com>

Brandon Casey <bcasey@nvidia.com> writes:

Show 26 quoted lines

> From: Brandon Casey <drafnel@gmail.com>
>
> The setting of denyDeleteCurrent applies to both bare and non-bare
> repositories.  Correct the description on this point, and expand it to
> provide some background justification for the current behavior and
> describe the full suite of settings.
>
> Signed-off-by: Brandon Casey <drafnel@gmail.com>
> ---
>  Documentation/config.txt | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index c3f7002..3d416ec 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1993,8 +1993,15 @@ receive.denyDeletes::
>  	the ref. Use this to prevent such a ref deletion via a push.
>  
>  receive.denyDeleteCurrent::
> -	If set to true, git-receive-pack will deny a ref update that
> -	deletes the currently checked out branch of a non-bare repository.
> +	If set to true or "refuse", git-receive-pack will deny a ref update
> +	that deletes the currently checked out branch of a non-bare repository,
> +	or the "default" branch in a bare repository.  i.e. the branch
> +	that HEAD refers to.

It reads just fine without the part that you found the need for clarification with "i.e.", i.e.

	or the branch that HEAD points at in a bare repository.

without introducing a new word "default branch" that is not defined in the glossary.

> +	Deleting the current branch from a remote will
> +	cause the HEAD symbolic ref to become dangling and will result in the
> +	next clone from it to not check out anything.

This sentence tells truth but does not fit in the logic flow in the paragraph. I am reading it as primarily meant to be an explanation why it would be a good idea to apply this seemingly non-bare only option (implied by "current" in its name---it is so rare for a bare repository to repoint its HEAD that the concept of "current" does not mesh well with a bare one) to a bare one. It may be a good thing to have, but the thought-process may flow better if it is made as a FYI after the main text, i.e.

                If set to true or "refuse", `git-receive-pack` will deny a
                ref update that deletes the branch that HAED points at.  If
                set to "warn", ... If set to false or "ignore", ... Defaults
                to "refuse".
        +
        Deleting the branch that HEAD points at will cause the HEAD symbolic
        ref to become dangling.  This causes the next commit to become a
        "root" commit, disconnected from the old history, in a non-bare
        repository.  It also causes the next clone from such a repository
        (either bare or non-bare) not to check out anything.

perhaps?