{"thread":{"id":"58515","subject":"[PATCH] receive.txt: Describe effect of denyDeleteCurrent on bare repositories","startedAt":"2022-09-26T09:06:57Z","lastAt":"2022-09-26T19:08:11Z","messageCount":2,"participants":["Andreas Schwab","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"463610","messageId":"mvmmtammrnt.fsf@suse.de","threadId":"58515","inReplyTo":null,"subject":"[PATCH] receive.txt: Describe effect of denyDeleteCurrent on bare repositories","fromName":"Andreas Schwab","fromEmail":"schwab@suse.de","sentAt":"2022-09-26T09:05:58Z","receivedAt":"2022-09-26T09:06:57Z","isPatch":true,"sender":{"key":"schwab@suse.de","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"The receive.denyDeleteCurrent config option not only affects non-bare\nrepositories, but also the default branch of a bare repository.\n\nSigned-off-by: Andreas Schwab \n---\n Documentation/config/receive.txt | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/config/receive.txt b/Documentation/config/receive.txt\nindex 85d5b5a3d2..07db745cd4 100644\n--- a/Documentation/config/receive.txt\n+++ b/Documentation/config/receive.txt\n@@ -80,7 +80,8 @@ receive.denyDeletes::\n \n receive.denyDeleteCurrent::\n \tIf set to true, git-receive-pack will deny a ref update that\n-\tdeletes the currently checked out branch of a non-bare repository.\n+\tdeletes the currently checked out branch of a non-bare repository,\n+\tor the default branch of a bare repository.\n \n receive.denyCurrentBranch::\n \tIf set to true or \"refuse\", git-receive-pack will deny a ref update\n-- \n2.37.3\n\n\n-- \nAndreas Schwab, SUSE Labs, schwab@suse.de\nGPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7\n\"And now for something completely different.\"\n"},{"id":"463662","messageId":"xmqqsfkeneh5.fsf@gitster.g","threadId":"58515","inReplyTo":"mvmmtammrnt.fsf@suse.de","subject":"Re: [PATCH] receive.txt: Describe effect of denyDeleteCurrent on bare repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-09-26T19:05:26Z","receivedAt":"2022-09-26T19:08:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab writes:\n\n> Subject: Re: [PATCH] receive.txt: Describe effect of denyDeleteCurrent on bare repositories\n\n\"Describe\" -> \"describe\"\n\n> The receive.denyDeleteCurrent config option not only affects non-bare\n> repositories, but also the default branch of a bare repository.\n\nWe call a branch that is pointed at with the HEAD symbolic-ref the\n\"current\" branch and I think that is why the configuration variable\nis called \"deny delet(ing) current (branch)\". I do not know if I\nhave heard the current branch in a bare repository called \"the\ndefault\", though.\n\nThe glossary says\n\n[[def_branch]]branch::\n\tA \"branch\" is a line of development. The most recent\n\t<> on a branch is referred to as the tip of\n\tthat branch. The tip of the branch is referenced by a branch\n\t<>, which moves forward as additional development\n\tis done on the branch. A single Git\n\t<> can track an arbitrary number of\n\tbranches, but your <> is\n\tassociated with just one of them (the \"current\" or \"checked out\"\n\tbranch), and <> points to that branch.\n\nand does not even mention a bare repository. \n\nStepping back a bit.\n\nThe primary reason for denying deletion of the \"current\" branch was\nto help those who \"clone\" from a repository with unborn HEAD\n(i.e. HEAD pointing at a branch that has no commits on it yet), so\nthe current behaviour, unlike receive.denyCurrentBranch that\ntriggers only in a non-bare repository, that prevents deletion in\neither a bare or a non-bare repository does make sense. \"git clone\"\nin recent versions of Git is much better handling such a situation,\nso it may no longer be necessary to keep this restriction, but it is\na different topic. I agree with this patch that we should document\nthe behaviour first.\n\nIt probably makes sense to update the glossary to talk about the\nbranch pointed at by HEAD in a bare repository. It is what the\nproject that owns the bare repository considers the primary branch\nits members would want to follow. Perhaps like the attached patch\n(if we want to keep the introduction of \"default branch\" phrase in\nthe patch I am responding to).\n\nA simpler alternative may be to say:\n\n ... deny a ref update that deletes the current branch that is\n pointed at by HEAD.\n\nin the patch I am responding to. I am OK with either approach.\n\nThanks.\n\n\n\n Documentation/glossary-content.txt | 9 ++++++++-\n 1 file changed, 8 insertions(+), 1 deletion(-)\n\ndiff --git i/Documentation/glossary-content.txt w/Documentation/glossary-content.txt\nindex 67c7a50b96..b20ded70d4 100644\n--- i/Documentation/glossary-content.txt\n+++ w/Documentation/glossary-content.txt\n@@ -26,7 +26,10 @@\n \t<> can track an arbitrary number of\n \tbranches, but your <> is\n \tassociated with just one of them (the \"current\" or \"checked out\"\n-\tbranch), and <> points to that branch.\n+\tbranch) at one time, and <> points to that branch.\n+\tA <> also has\n+\t<> that points at the primary branch (the\n+\t\"default\" branch) of the project.\n \n [[def_cache]]cache::\n \tObsolete for: <>.\n@@ -197,6 +200,10 @@ for a more flexible and robust system to do the same thing.\n \t<> in your repository, except when using a\n \t<>, in which case it directly\n \treferences an arbitrary commit.\n++\n+In a <>, HEAD points at a branch\n+that is considered the primary branch (the \"default\" branch) of the\n+project.\n \n [[def_head_ref]]head ref::\n \tA synonym for <>.\n\n\n\n\n"}]}