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