{"thread":{"id":"35148","subject":"[PATCH] Documentation/config.txt: denyDeleteCurrent applies to bare repos too","startedAt":"2013-10-16T01:26:58Z","lastAt":"2013-10-17T23:29:35Z","messageCount":3,"participants":["Brandon Casey","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"229053","messageId":"1381886818-14337-1-git-send-email-bcasey@nvidia.com","threadId":"35148","inReplyTo":null,"subject":"[PATCH] Documentation/config.txt: denyDeleteCurrent applies to bare repos too","fromName":"Brandon Casey","fromEmail":"bcasey@nvidia.com","sentAt":"2013-10-16T01:26:58Z","receivedAt":"2013-10-16T01:26:58Z","isPatch":true,"sender":{"key":"bcasey@nvidia.com","avatar":null},"body":"From: Brandon Casey <drafnel@gmail.com>\n\nThe setting of denyDeleteCurrent applies to both bare and non-bare\nrepositories.  Correct the description on this point, and expand it to\nprovide some background justification for the current behavior and\ndescribe the full suite of settings.\n\nSigned-off-by: Brandon Casey <drafnel@gmail.com>\n---\n Documentation/config.txt | 11 +++++++++--\n 1 file changed, 9 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex c3f7002..3d416ec 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1993,8 +1993,15 @@ receive.denyDeletes::\n \tthe ref. Use this to prevent such a ref deletion via a push.\n \n receive.denyDeleteCurrent::\n-\tIf set to true, git-receive-pack will deny a ref update that\n-\tdeletes the currently checked out branch of a non-bare repository.\n+\tIf set to true or \"refuse\", git-receive-pack will deny a ref update\n+\tthat deletes the currently checked out branch of a non-bare repository,\n+\tor the \"default\" branch in a bare repository.  i.e. the branch\n+\tthat HEAD refers to.  Deleting the current branch from a remote will\n+\tcause the HEAD symbolic ref to become dangling and will result in the\n+\tnext clone from it to not check out anything.  If set to \"warn\",\n+\tthen a warning will be printed to stderr and the deletion will be\n+\tperformed.  If set to false or \"ignore\", then the deletion will be\n+\tperformed with no warning message.  Defaults to \"refuse\".\n \n receive.denyCurrentBranch::\n \tIf set to true or \"refuse\", git-receive-pack will deny a ref update\n-- \n1.8.4.rc4.6.g5555d19\n\n\n-----------------------------------------------------------------------------------\nThis email message is for the sole use of the intended recipient(s) and may contain\nconfidential information.  Any unauthorized review, use, disclosure or distribution\nis prohibited.  If you are not the intended recipient, please contact the sender by\nreply email and destroy all copies of the original message.\n-----------------------------------------------------------------------------------\n"},{"id":"229149","messageId":"xmqq4n8fy1t3.fsf@gitster.dls.corp.google.com","threadId":"35148","inReplyTo":"1381886818-14337-1-git-send-email-bcasey@nvidia.com","subject":"Re: [PATCH] Documentation/config.txt: denyDeleteCurrent applies to bare repos too","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-17T22:23:20Z","receivedAt":"2013-10-17T22:23:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Casey <bcasey@nvidia.com> writes:\n\n> From: Brandon Casey <drafnel@gmail.com>\n>\n> The setting of denyDeleteCurrent applies to both bare and non-bare\n> repositories.  Correct the description on this point, and expand it to\n> provide some background justification for the current behavior and\n> describe the full suite of settings.\n>\n> Signed-off-by: Brandon Casey <drafnel@gmail.com>\n> ---\n>  Documentation/config.txt | 11 +++++++++--\n>  1 file changed, 9 insertions(+), 2 deletions(-)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index c3f7002..3d416ec 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -1993,8 +1993,15 @@ receive.denyDeletes::\n>  \tthe ref. Use this to prevent such a ref deletion via a push.\n>  \n>  receive.denyDeleteCurrent::\n> -\tIf set to true, git-receive-pack will deny a ref update that\n> -\tdeletes the currently checked out branch of a non-bare repository.\n> +\tIf set to true or \"refuse\", git-receive-pack will deny a ref update\n> +\tthat deletes the currently checked out branch of a non-bare repository,\n> +\tor the \"default\" branch in a bare repository.  i.e. the branch\n> +\tthat HEAD refers to.\n\nIt reads just fine without the part that you found the need for\nclarification with \"i.e.\", i.e.\n\n\tor the branch that HEAD points at in a bare repository.\n\nwithout introducing a new word \"default branch\" that is not defined\nin the glossary.\n\n> +\tDeleting the current branch from a remote will\n> +\tcause the HEAD symbolic ref to become dangling and will result in the\n> +\tnext clone from it to not check out anything.\n\nThis sentence tells truth but does not fit in the logic flow in the\nparagraph. I am reading it as primarily meant to be an explanation\nwhy it would be a good idea to apply this seemingly non-bare only\noption (implied by \"current\" in its name---it is so rare for a bare\nrepository to repoint its HEAD that the concept of \"current\" does\nnot mesh well with a bare one) to a bare one. It may be a good thing\nto have, but the thought-process may flow better if it is made as a\nFYI after the main text, i.e.\n\n                If set to true or \"refuse\", `git-receive-pack` will deny a\n                ref update that deletes the branch that HAED points at.  If\n                set to \"warn\", ... If set to false or \"ignore\", ... Defaults\n                to \"refuse\".\n        +\n        Deleting the branch that HEAD points at will cause the HEAD symbolic\n        ref to become dangling.  This causes the next commit to become a\n        \"root\" commit, disconnected from the old history, in a non-bare\n        repository.  It also causes the next clone from such a repository\n        (either bare or non-bare) not to check out anything.\n\nperhaps?\n"},{"id":"229154","messageId":"CA+sFfMfxaM7z5kWyi_5pOjSLYy3BEstUZiG759QyZfjqobCdNg@mail.gmail.com","threadId":"35148","inReplyTo":"xmqq4n8fy1t3.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] Documentation/config.txt: denyDeleteCurrent applies to bare repos too","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2013-10-17T23:29:35Z","receivedAt":"2013-10-17T23:29:35Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Thu, Oct 17, 2013 at 3:23 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Brandon Casey <bcasey@nvidia.com> writes:\n>\n>> From: Brandon Casey <drafnel@gmail.com>\n>>\n>> The setting of denyDeleteCurrent applies to both bare and non-bare\n>> repositories.  Correct the description on this point, and expand it to\n>> provide some background justification for the current behavior and\n>> describe the full suite of settings.\n>>\n>> Signed-off-by: Brandon Casey <drafnel@gmail.com>\n>> ---\n>>  Documentation/config.txt | 11 +++++++++--\n>>  1 file changed, 9 insertions(+), 2 deletions(-)\n>>\n>> diff --git a/Documentation/config.txt b/Documentation/config.txt\n>> index c3f7002..3d416ec 100644\n>> --- a/Documentation/config.txt\n>> +++ b/Documentation/config.txt\n>> @@ -1993,8 +1993,15 @@ receive.denyDeletes::\n>>       the ref. Use this to prevent such a ref deletion via a push.\n>>\n>>  receive.denyDeleteCurrent::\n>> -     If set to true, git-receive-pack will deny a ref update that\n>> -     deletes the currently checked out branch of a non-bare repository.\n>> +     If set to true or \"refuse\", git-receive-pack will deny a ref update\n>> +     that deletes the currently checked out branch of a non-bare repository,\n>> +     or the \"default\" branch in a bare repository.  i.e. the branch\n>> +     that HEAD refers to.\n>\n> It reads just fine without the part that you found the need for\n> clarification with \"i.e.\", i.e.\n>\n>         or the branch that HEAD points at in a bare repository.\n>\n> without introducing a new word \"default branch\" that is not defined\n> in the glossary.\n\nEither way is fine with me.  The phrase \"the branch that HEAD points\nat\" applies to either a bare or non-bare repo though, so the \"i.e.\"\nwas directed at both parts of the preceding sentence.  Guess we\nhaven't defined an alternative way to say \"the branch that HEAD points\nat\" for a bare repository à la \"currently checked out branch\" for a\nnon-bare repository.\n\n>> +     Deleting the current branch from a remote will\n>> +     cause the HEAD symbolic ref to become dangling and will result in the\n>> +     next clone from it to not check out anything.\n>\n> This sentence tells truth but does not fit in the logic flow in the\n> paragraph. I am reading it as primarily meant to be an explanation\n> why it would be a good idea to apply this seemingly non-bare only\n> option (implied by \"current\" in its name---it is so rare for a bare\n> repository to repoint its HEAD that the concept of \"current\" does\n> not mesh well with a bare one) to a bare one.\n\nYep, that's the correct reading: as an explanation for why this should\napply to bare repos as well as non-bare.\n\n> It may be a good thing\n> to have, but the thought-process may flow better if it is made as a\n> FYI after the main text, i.e.\n>\n>                 If set to true or \"refuse\", `git-receive-pack` will deny a\n>                 ref update that deletes the branch that HAED points at.  If\n>                 set to \"warn\", ... If set to false or \"ignore\", ... Defaults\n>                 to \"refuse\".\n>         +\n>         Deleting the branch that HEAD points at will cause the HEAD symbolic\n>         ref to become dangling.  This causes the next commit to become a\n>         \"root\" commit, disconnected from the old history, in a non-bare\n>         repository.  It also causes the next clone from such a repository\n>         (either bare or non-bare) not to check out anything.\n>\n> perhaps?\n\nYes, much better as a note following the main text.  Thanks.\n\n-Brandon\n"}]}