From: Junio C Hamano <gitster@pobox.com>
To: Asheesh Laroia <asheesh@asheesh.org>
Cc: Johannes Schindelin <johannes.schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
Date: Tue, 13 Apr 2010 10:57:50 -0700 [thread overview]
Message-ID: <7vtyrfutep.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.DEB.2.00.0901291729540.22558@vellum.laroia.net> (Asheesh Laroia's message of "Thu\, 29 Jan 2009 17\:32\:27 -0800 \(PST\)")
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
next prev parent reply other threads:[~2010-04-13 17:58 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1233275583u.git.johannes.schindelin@gmx.de>
2009-01-30 0:34 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Johannes Schindelin
2009-01-30 1:28 ` Jay Soffian
2009-01-30 1:32 ` Asheesh Laroia
2010-04-13 16:42 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Dave Abrahams
2010-04-13 17:57 ` Junio C Hamano [this message]
[not found] ` <7v4ozhd1wp.fsf@gitster.siamese.dyndns.org>
2009-01-30 2:18 ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Junio C Hamano
2009-01-30 13:24 ` Johannes Schindelin
2009-01-30 16:33 ` Jeff King
2009-01-30 16:55 ` Johannes Schindelin
2009-01-30 2:30 ` Miklos Vajna
2009-01-30 13:28 ` Johannes Schindelin
2009-02-11 0:11 ` Miklos Vajna
2009-02-11 1:04 ` Junio C Hamano
2009-01-30 2:55 ` Jeff King
2009-01-30 14:11 ` Johannes Schindelin
2009-01-30 7:17 ` Johannes Sixt
2009-01-30 7:34 ` Jeff King
2009-01-30 13:23 ` Johannes Schindelin
2009-01-30 14:35 ` Jeff King
2009-01-30 16:17 ` Jay Soffian
2009-01-30 16:28 ` Jeff King
2009-01-30 17:01 ` Johannes Schindelin
2009-01-30 18:50 ` Jay Soffian
2009-01-30 19:03 ` Johannes Schindelin
2009-01-31 0:56 ` Nanako Shiraishi
2009-02-01 1:27 ` Junio C Hamano
2009-02-01 1:39 ` Junio C Hamano
2009-02-02 12:41 ` Jeff King
2009-02-03 4:30 ` Junio C Hamano
2009-02-03 17:45 ` Junio C Hamano
2009-02-06 14:06 ` Jeff King
2009-02-07 7:51 ` Junio C Hamano
2009-02-03 8:01 ` Junio C Hamano
2009-02-03 8:07 ` Jeff King
2009-02-03 9:22 ` Junio C Hamano
2009-02-01 2:06 ` Junio C Hamano
2009-02-01 3:37 ` Sam Vilain
2009-02-01 21:33 ` Junio C Hamano
2009-02-02 7:00 ` Sam Vilain
2009-02-02 8:32 ` Junio C Hamano
2009-02-02 10:50 ` Sam Vilain
2009-02-01 22:59 ` Johannes Schindelin
2009-02-01 23:56 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vtyrfutep.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=asheesh@asheesh.org \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).