| Message ID | mvmmtammrnt.fsf@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | receive.txt: Describe effect of denyDeleteCurrent on bare repositories | expand |
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>>.
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
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(-)