On Thu, Oct 17, 2013 at 3:23 PM, Junio C Hamano <gits...@pobox.com> wrote: > Brandon Casey <bca...@nvidia.com> writes: > >> From: Brandon Casey <draf...@gmail.com> >> >> 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 <draf...@gmail.com> >> --- >> 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.
Either way is fine with me. The phrase "the branch that HEAD points at" applies to either a bare or non-bare repo though, so the "i.e." was directed at both parts of the preceding sentence. Guess we haven't defined an alternative way to say "the branch that HEAD points at" for a bare repository à la "currently checked out branch" for a non-bare repository. >> + 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. Yep, that's the correct reading: as an explanation for why this should apply to bare repos as well as non-bare. > 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? Yes, much better as a note following the main text. Thanks. -Brandon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
