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