git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
Date: Fri, 30 Jan 2009 14:24:57 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.1.00.0901301423120.3586@pacific.mpi-cbg.de> (raw)
In-Reply-To: <7vwscdbkpd.fsf@gitster.siamese.dyndns.org>

Hi,

On Thu, 29 Jan 2009, Junio C Hamano wrote:

> @@ -239,9 +239,12 @@ static const char *update(struct command *cmd)
>  			" that are now in HEAD.");
>  		break;
>  	case DENY_REFUSE:
> -		if (!is_ref_checked_out(name))
> +		if (is_bare_repository() || !is_ref_checked_out(name))
>  			break;
> -		error("refusing to update checked out branch: %s", name);
> +		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);
>  		return "branch is currently checked out";
>  	}
>  
> As the message I am currently getting from such a push is:
> 
> $ git push ../victim-010 next:master
> Total 0 (delta 0), reused 0 (delta 0)
> warning: updating the currently checked out branch; this may cause confusion,
> as the index and working tree do not reflect changes that are now in HEAD.
> To ../victim-010
>    a34a9db..d79e69c  next -> master
> 
> which is much better than what you did.  It at least tries to explain why
> it is warning, even though I think it has a huge room for improvement.

I do not really care about the output.  You are probably right, it should 
be different from what I proposed.

> You alluded that we wanted to make grace period much longer, but you 
> want to cut it short.  I think it is a huge mistake.  The warning has 
> only been there for the last two months, and only can be seen from 
> v1.6.1-rc1 or newer software.  These new people even haven't a chance to 
> learn from the existing warning.

In reality, people will not learn from the warning.  Those that are 
old-timers (and who should be warned in the first place, instead of 
refuses) will just happily ignore that there was a warning: the command 
they used so often and the worked all the time just happened to work -- 
again -- no matter what the output is.

But we are really hurting new users, and let's face it, the balance of 
time cost currently is in a huge favor of the old-timers there.

Not only are there many more newbies these days than old timers.

No, the _time_ spent by an old-timer to read an appropriate message and 
fix the setup would be _substantially_ shorter than the _hours_ of 
frustration a newbie spends on the issue.

And we claim to make decentralized repositories easy.

> I think what would work much better would be a patch that keeps the
> warn-but-allow as the default, but clarifies the warning message.

As I said, I am _convinced_ that a warning will do nothing at all.  Just 
like the warning about the dashed commands, nobody who should be concerned 
will notice it.

>  (1) what symptoms, that are easily observable by the most novice users,
>      are caused by "index and work tree going out of sync" the warning
>      talks about, and why that would not be what they want;
> 
>  (2) if the user did not mean to do it (and the user can tell by observing
>      the symptom described in the previous point), describe what needs to
>      be done to recover from the fallout this push has caused (we do not
>      need a recipe; pointing at a URL or manpage is fine), and what switch
>      to flip to prevent herself from doing it again in the future;
> 
>  (3) if the user did mean it, and finds the above two big warning
>      annoying, what switch to flip to squelch the warning for future
>      pushes.
> 
> The goal of the warning should be to *force* people *choose*, either to
> silently-allow (aka DENY_IGNORE) or refuse (DENY_REFUSE), and give enough
> information for them to make an informed decision.  We can afford to be
> annoyingly long, loud and verbose there.
> 
> On the other hand, you cannot make the message for DENY_REFUSE annoyingly
> long, as people may have already chosen to say "please refuse my push into
> a live branch".
> 
> If you are making "refuse" the default, an annoyingly long message is even
> worse.  "Yeah, thanks for stopping me, but you do not have to remind me
> every time that I made a mistake in large red letters.  I perfectly well
> know what I am doing, I perfectly well know that I did not want to push
> into that branch, I just made a mistake---you do not have to be so loud".
> 
> I suspect that you cannot even be long enough to be informative, not to
> annoy people.

Let's reap all the opinions about this issue, and then I'll do the wrap-up 
patch.

But this is a serious issue that seriously needs to be coped with.  We are 
getting another generation of "Git is difficult" users that way.

Ciao,
Dscho

  reply	other threads:[~2009-01-30 13:26 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 &quot;refuse&quot; Dave Abrahams
2010-04-13 17:57     ` [PATCH] Switch receive.denyCurrentBranch to "refuse" Junio C Hamano
     [not found]   ` <7v4ozhd1wp.fsf@gitster.siamese.dyndns.org>
2009-01-30  2:18     ` Junio C Hamano
2009-01-30 13:24       ` Johannes Schindelin [this message]
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=alpine.DEB.1.00.0901301423120.3586@pacific.mpi-cbg.de \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).