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

[Junio C Hamano <gitster@pobox.com>]

Asheesh Laroia <asheesh@asheesh.org> writes:

> On Fri, 30 Jan 2009, Johannes Schindelin wrote:
>
>> 	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