[PATCH] receive.txt: Describe effect of denyDeleteCurrent on bare repositories

[PATCH] receive.txt: Describe effect of denyDeleteCurrent on bare repositories

[Andreas Schwab]

The receive.denyDeleteCurrent config option not only affects non-bare
repositories, but also the default branch of a bare repository.

Signed-off-by: Andreas Schwab <schwab@suse.de>
---
 Documentation/config/receive.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/config/receive.txt b/Documentation/config/receive.txt
index 85d5b5a3d2..07db745cd4 100644
--- a/Documentation/config/receive.txt
+++ b/Documentation/config/receive.txt
@@ -80,7 +80,8 @@ receive.denyDeletes::
 
 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.
+	deletes the currently checked out branch of a non-bare repository,
+	or the default branch of a bare repository.
 
 receive.denyCurrentBranch::
 	If set to true or "refuse", git-receive-pack will deny a ref update
-- 
2.37.3


-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] receive.txt: Describe effect of denyDeleteCurrent on bare repositories

[Junio C Hamano]

Andreas Schwab <schwab@suse.de> writes:

> Subject: Re: [PATCH] receive.txt: Describe effect of denyDeleteCurrent on bare repositories

"Describe" -> "describe"

> The receive.denyDeleteCurrent config option not only affects non-bare
> repositories, but also the default branch of a bare repository.

We call a branch that is pointed at with the HEAD symbolic-ref the
"current" branch and I think that is why the configuration variable
is called "deny delet(ing) current (branch)".  I do not know if I
have heard the current branch in a bare repository called "the
default", though.

The glossary says

[[def_branch]]branch::
	A "branch" is a line of development.  The most recent
	<<def_commit,commit>> on a branch is referred to as the tip of
	that branch.  The tip of the branch is referenced by a branch
	<<def_head,head>>, which moves forward as additional development
	is done on the branch.  A single Git
	<<def_repository,repository>> can track an arbitrary number of
	branches, but your <<def_working_tree,working tree>> is
	associated with just one of them (the "current" or "checked out"
	branch), and <<def_HEAD,HEAD>> points to that branch.

and does not even mention a bare repository.  

Stepping back a bit.

The primary reason for denying deletion of the "current" branch was
to help those who "clone" from a repository with unborn HEAD
(i.e. HEAD pointing at a branch that has no commits on it yet), so
the current behaviour, unlike receive.denyCurrentBranch that
triggers only in a non-bare repository, that prevents deletion in
either a bare or a non-bare repository does make sense.  "git clone"
in recent versions of Git is much better handling such a situation,
so it may no longer be necessary to keep this restriction, but it is
a different topic.  I agree with this patch that we should document
the behaviour first.

It probably makes sense to update the glossary to talk about the
branch pointed at by HEAD in a bare repository.  It is what the
project that owns the bare repository considers the primary branch
its members would want to follow.  Perhaps like the attached patch
(if we want to keep the introduction of "default branch" phrase in
the patch I am responding to).

A simpler alternative may be to say:

     ... deny a ref update that deletes the current branch that is
     pointed at by HEAD.

in the patch I am responding to.  I am OK with either approach.

Thanks.



 Documentation/glossary-content.txt | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git i/Documentation/glossary-content.txt w/Documentation/glossary-content.txt
index 67c7a50b96..b20ded70d4 100644
--- i/Documentation/glossary-content.txt
+++ w/Documentation/glossary-content.txt
@@ -26,7 +26,10 @@
 	<<def_repository,repository>> can track an arbitrary number of
 	branches, but your <<def_working_tree,working tree>> is
 	associated with just one of them (the "current" or "checked out"
-	branch), and <<def_HEAD,HEAD>> points to that branch.
+	branch) at one time, and <<def_HEAD,HEAD>> points to that branch.
+	A <<def_bare_repository,bare repository>> also has
+	<<def_HEAD,HEAD>> that points at the primary branch (the
+	"default" branch) of the project.
 
 [[def_cache]]cache::
 	Obsolete for: <<def_index,index>>.
@@ -197,6 +200,10 @@ for a more flexible and robust system to do the same thing.
 	<<def_head,heads>> in your repository, except when using a
 	<<def_detached_HEAD,detached HEAD>>, in which case it directly
 	references an arbitrary commit.
++
+In a <<def_bare_repository,bare repository>>, HEAD points at a branch
+that is considered the primary branch (the "default" branch) of the
+project.
 
 [[def_head_ref]]head ref::
 	A synonym for <<def_head,head>>.