Brandon Casey <[email protected]> writes:
> From: Brandon Casey <[email protected]>
>
> 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 <[email protected]>
> ---
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
