Re: [PATCH] Documentation/config.txt: denyDeleteCurrent applies to bare repos too
Brandon Casey bca...@nvidia.com writes: From: Brandon Casey draf...@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 draf...@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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/config.txt: denyDeleteCurrent applies to bare repos too
On Thu, Oct 17, 2013 at 3:23 PM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey bca...@nvidia.com writes: From: Brandon Casey draf...@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 draf...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation/config.txt: denyDeleteCurrent applies to bare repos too
From: Brandon Casey draf...@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 draf...@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.gd19 --- 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. --- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
