git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Jan 30, 2009, 13:24 UTC
Message-ID
<alpine.DEB.1.00.0901301423120.3586@pacific.mpi-cbg.de>
In-Reply-To
<7vwscdbkpd.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 29 Jan 2009, Junio C Hamano wrote:
Show 26 quoted lines
> @@ -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.

Show 5 quoted lines
> 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.

Show 31 quoted lines
>  (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

Previous: Junio C HamanoNext: Jeff King
Message 41 of 43 in “Switch receive.denyCurrentBranch to "refuse"”
  1. Switch receive.denyCurrentBranch to "refuse"Johannes Schindelin, Jan 30, 2009
  2. Jay SoffianJan 30, 2009
  3. Asheesh LaroiaJan 30, 2009
  4. Dave AbrahamsApr 13, 2010
  5. Junio C HamanoApr 13, 2010
  6. Miklos VajnaJan 30, 2009
  7. Johannes SchindelinJan 30, 2009
  8. Miklos VajnaFeb 11, 2009
  9. Junio C HamanoFeb 11, 2009
  10. Jeff KingJan 30, 2009
  11. Johannes SchindelinJan 30, 2009
  12. Johannes SixtJan 30, 2009
  13. Jeff KingJan 30, 2009
  14. Johannes SchindelinJan 30, 2009
  15. Jeff KingJan 30, 2009
  16. Jay SoffianJan 30, 2009
  17. Jeff KingJan 30, 2009
  18. Johannes SchindelinJan 30, 2009
  19. Jay SoffianJan 30, 2009
  20. Johannes SchindelinJan 30, 2009
  21. Nanako ShiraishiJan 31, 2009
  22. Junio C HamanoFeb 1, 2009
  23. Junio C HamanoFeb 1, 2009
  24. Jeff KingFeb 2, 2009
  25. Junio C HamanoFeb 3, 2009
  26. Junio C HamanoFeb 3, 2009
  27. Jeff KingFeb 6, 2009
  28. Junio C HamanoFeb 7, 2009
  29. Junio C HamanoFeb 3, 2009
  30. Jeff KingFeb 3, 2009
  31. Junio C HamanoFeb 3, 2009
  32. Junio C HamanoFeb 1, 2009
  33. Sam VilainFeb 1, 2009
  34. Junio C HamanoFeb 1, 2009
  35. Sam VilainFeb 2, 2009
  36. Junio C HamanoFeb 2, 2009
  37. Sam VilainFeb 2, 2009
  38. Johannes SchindelinFeb 1, 2009
  39. Junio C HamanoFeb 1, 2009
  40. Junio C HamanoJan 30, 2009
  41. Johannes SchindelinJan 30, 2009
  42. Jeff KingJan 30, 2009
  43. Johannes SchindelinJan 30, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.