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

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

[Brandon Casey]

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.  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.  If set to "warn",
+	then a warning will be printed to stderr and the deletion will be
+	performed.  If set to false or "ignore", then the deletion will be
+	performed with no warning message.  Defaults to "refuse".
 
 receive.denyCurrentBranch::
 	If set to true or "refuse", git-receive-pack will deny a ref update
-- 
1.8.4.rc4.6.g5555d19


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

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

[Junio C Hamano]

Brandon Casey <bcasey@nvidia.com> writes:

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

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

[Brandon Casey]

On Thu, Oct 17, 2013 at 3:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <bcasey@nvidia.com> writes:
>
>> 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.

Either way is fine with me.  The phrase "the branch that HEAD points
at" applies to either a bare or non-bare repo though, so the "i.e."
was directed at both parts of the preceding sentence.  Guess we
haven't defined an alternative way to say "the branch that HEAD points
at" for a bare repository à la "currently checked out branch" for a
non-bare repository.

>> +     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.

Yep, that's the correct reading: as an explanation for why this should
apply to bare repos as well as non-bare.

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

Yes, much better as a note following the main text.  Thanks.

-Brandon