* Re: [PATCH] receive.txt: Describe effect of denyDeleteCurrent on bare repositories
2022-09-26 9:05 [PATCH] receive.txt: Describe effect of denyDeleteCurrent on bare repositories Andreas Schwab
@ 2022-09-26 19:05 ` Junio C Hamano
0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2022-09-26 19:05 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
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>>.
^ permalink raw reply related [flat|nested] 2+ messages in thread