Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"

Asheesh Laroia [off-list ref] writes:

On Fri, 30 Jan 2009, Johannes Schindelin wrote:

quoted

	case DENY_REFUSE:
+		if (is_bare_repository() || !is_ref_checked_out(name))
			break;
+		error("refusing to update checked out branch: %s\n"
+			"if you know what you are doing, you can allow it by "
+			"setting\n\n"
+			"\tgit config receive.denyCurrentBranch true\n", name);

Being told how to do it right is even better than being told that
you're doing it wrong. (-:

Of course you are correct, but there are two _right ways_ that are
completely different, depending on how the repository you are pushing
into is meant to be used:

 - If you are using it as a shared central repository, a distribution
   point, or a back-up location, you don't need a working tree, and
   as you say, the "checked out branch" condition will not trigger, if
   you made it a bare one.

 - People do wish a way to keep a repository with a checkout, and that is
   often the reason why this codepath is triggered.  They want a checkout
   in the repository (perhaps they are serving the files in them from a
   webserver).  For them, "pushing into it" is not the ultimate goal, but
   "having its working tree and keeping it up-to-date" is.  For that,
   pushing into a "reception branch" and merging that to the checkout from
   the post-update hook is probably the right way (Cf. [*1*] especially is
   "See also ...").

Also I do not think it would help users to suggest "bare repository"
even for the first class of users.

 - If the user knows what a "bare" repository is, the user would realize
   "Hmm, I am not allowed to push to the checked out branch?  Wait, this
   repository does not even need a working tree, so if I make it a bare
   one, I wouldn't have any checked out branch by definition and I
   wouldn't have this issue" without being told.

 - If the user does not know what a "bare" repository is, the user may not
   even realize that the target repository does not have to have a working
   tree.  In such a case, there won't be a mental "click" between "checked
   out" and "bare" anyway.  The added message to suggest "bare" will be
   another line of unintelligible gitspeak in the message to them.


[Reference]

*1* https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F