From: Jeff King <peff@peff.net>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: Johannes Sixt <j.sixt@viscovery.net>,
Caleb Cushing <xenoterracide@gmail.com>,
git@vger.kernel.org
Subject: Re: git push origin error (1.6.3 new default functionality)
Date: Thu, 14 May 2009 02:31:57 -0400 [thread overview]
Message-ID: <20090514063157.GA10411@coredump.intra.peff.net> (raw)
In-Reply-To: <4A0A98CC.2090701@drmicha.warpmail.net>
On Wed, May 13, 2009 at 11:54:20AM +0200, Michael J Gruber wrote:
> > Regardless, my point was: the warning was introduced for a purpose
> > (either to point out potentially confusing behavior, or to warn the user
> > about an upcoming change in default behavior). Showing up now and saying
> > "I don't like this warning" without addressing any of the points in the
> > original discussion or making any sort of proposal to try to accomplish
> > the same goals is just counterproductive.
>
> I don't want to stir this up to much again - as I said, set config and
> be done.
Junio already posted a thoughtful (if perhaps somewhat frustrated) reply
elsewhere, and I agree with most of what he said. I did want to make one
additional point, though, because I think what I said may have appeared
mean. And I was really trying to be nice.
My initial reaction was to say "shut up and set the config variable".
But I really don't like doing that, because I don't want somebody
thinking that all decisions are closed, and it's not possible to come to
the table with new points that may make people change their minds.
When the subject was discussed before, there were people who preferred
various behaviors. They each made arguments, and in the aftermath, Junio
made a decision (presumably based on arguments by list members, opinions
of other developers, and whatever he thought was best) about what to
apply.
If somebody wants to bring up a new argument, new data, or point out
some or changed circumstance that may affect the decision, then I am all
for them doing so. And that is what I was trying to coax out of Caleb.
But without that, I don't see any reason why others should waste their
time reconsidering the decision. Let's assume that the original decision
making process was at least roughly deterministic and would just arrive
at the same answer.
And I think simply posting a "I would have been on the side to prefer X"
opinion isn't really new data. It pushes the tally for that preference
up by one, but the margin of error on such tallies is already huge (I
think we have seen in the past that there is a silent majority who are
_not_ on the git list, and we need to try to address their interests as
well). So while something like a well-managed survey of what git users
would prefer is new data, I consider a single (or even several) "me too"
messages on the list to just be noise in the data.
> My main issue is the fact that we have a config variable (push.default)
> which causes a different behaviour depending on whether it is unset or
> set to its default (!) value. That is a completely new UI approach. We
Well, it depends on how you think of the default. The default could be
"matched-and-warn", and you are fixing it by setting it to "matched". :)
-Peff
next prev parent reply other threads:[~2009-05-14 6:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-12 1:26 git push origin error (1.6.3 new default functionality) Caleb Cushing
2009-05-12 11:11 ` Michael J Gruber
2009-05-13 5:26 ` Caleb Cushing
2009-05-13 8:32 ` Jeff King
2009-05-13 8:44 ` Johannes Sixt
2009-05-13 9:03 ` Jeff King
2009-05-13 9:54 ` Michael J Gruber
2009-05-14 6:31 ` Jeff King [this message]
2009-05-14 7:37 ` Michael J Gruber
2009-05-13 18:37 ` Junio C Hamano
2009-05-14 3:30 ` Caleb Cushing
2009-05-14 4:44 ` Junio C Hamano
2009-05-14 5:29 ` Junio C Hamano
2009-05-14 8:57 ` Finn Arne Gangstad
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=20090514063157.GA10411@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.net \
--cc=xenoterracide@gmail.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).