Git Mailing List Archive on
 help / color / Atom feed
From: John Szakmeister <>
To: Felipe Contreras <>
Cc: Krzysztof Mazur <>,
Subject: Re: [PATCH v3] Add core.mode configuration
Date: Wed, 16 Oct 2013 06:54:31 -0400
Message-ID: <> (raw)
In-Reply-To: <525e0e1b28c87_81a151de743f@nysa.notmuch>

On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras
<> wrote:
> We cannot change the behavior of push.default = simple already, so at least
> that option is not in question.


> Presumably you are worried about the other options that can't be enabled in any
> way.


> But think about this; you are worried that if we add an *option* to enable this
> new behaviors, then we would be kind of forced to keep these behaviors. That
> seems to imply that you are proposing the current default; we wait until 2.0
> and not make it an *option*, but make it *default*.
> I think waiting until 2.0 to make it a default without evern having an option,
> and thus nobody actuallly testing this, is way worst than what I'm proposing;
> to add an option to start testing.

My concern is that people don't treat it for what it is--a way to
experiment with the new behaviors--and then they get upset if we
discover that some behavior was not well thought out and it disappears
"unexpectedly" when we correct the matter.  We have a balance to
strike: annoying users and getting some miles on the new behaviors.  I
see the technical end of this--your proposal to have a
'core.mode'--but where is the non-technical end of this argument?
What message are we proposing to send to the users?  What's our
promise to them surrounding core.mode and the new behaviors it offers?
 Perhaps we don't have much today that this affects, but what about
tomorrow?  Are we saying that behaviors enabled by core.mode=next are
concrete (they're going in as-is, and we won't alter their behavior
before 2.0)?

As I said, the only real drawback is that I see this as the latter,
because any other choice means users will get annoyed when something
changes out from under them.

>> So, at the end of the day, I'm just not sure it's worthwhile to have.
> This is exactly what happened on 1.6; nobody really tested the 'git foo'
> behavior, so we just switched from one version to the next. If you are not
> familiar with the outcome; it wasn't good.

You're right, I wasn't around for that.  And on the whole, I
absolutely agree: it's nice to get miles on these new
behaviors/features/etc.  I just worry that having an option like this
means we've committed to it, and I'm not sure that we want to give up
the ability to change them without having to go through some sort of
deprecation cycle.  Or worse, we have to wait until 3.0 and 2.0 hasn't
even come out yet.

I hope others chime in here.  And don't mistake me as dissenting; I'm
not.  And, I'm not assenting either.  I just want to know if you've
thought about what this means to users, and what we're prepared to
deal with.  Right now, I feel like half the argument around the option
is missing.

> So I say we shouldn't just provide warnings, but also have an option to allow
> users (probably a minority) to start testing this.

"probably a minority" -- I guess that's the part I disagree with.  I'm
not sure what a minority means here, but I don't think it'll be a
handful of people.  How big does that number get before we get
concerned about backlash from users if we decide to change course?
Or, is that simply not an issue?  Why or why not?  I have to be
honest, if the option was available, I'd have my developers turn it
on.  I'm sure a great deal of others would do so too.

Is there some other way we can solve this?  Having an experimental
branch with all the 2.0 features merged and those concerned can just
build that version?  I see the downside of that too: it's not as easy
for people to try, and there is nothing preventing folks from posting
binaries with the new behaviors enabled.  It leads me to feeling that
we're stuck in some regard.  But maybe I'm being overly pessimistic
here, and it's really all a non-issue.  As I said earlier, it'd be
nice if others chimed in here.


  parent reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-12  7:04 Felipe Contreras
2013-10-14 20:59 ` Krzysztof Mazur
2013-10-14 21:35   ` Felipe Contreras
2013-10-15 12:35     ` Krzysztof Mazur
2013-10-15 12:32       ` Felipe Contreras
2013-10-15 13:33         ` Krzysztof Mazur
2013-10-15 13:29           ` Felipe Contreras
2013-10-15 14:51             ` Krzysztof Mazur
2013-10-15 16:59               ` John Szakmeister
2013-10-16  3:55                 ` Felipe Contreras
2013-10-16  7:09                   ` Krzysztof Mazur
2013-10-16 19:31                     ` Felipe Contreras
2013-10-16 10:54                   ` John Szakmeister [this message]
2013-10-16 15:11                     ` John Szakmeister
2013-10-16 19:57                       ` Felipe Contreras
2013-10-16 19:32                     ` Felipe Contreras
2013-10-16 22:02                       ` Philip Oakley
2013-10-16 23:06                         ` Jonathan Nieder
2013-10-17 19:48                           ` Philip Oakley
2013-10-17 21:08                           ` Felipe Contreras
2013-10-15 18:51               ` Felipe Contreras
2013-10-15 22:01                 ` Krzysztof Mazur
2013-10-16  4:03                   ` Felipe Contreras
2013-10-16  6:34                     ` Krzysztof Mazur
2013-10-16 19:28                       ` Felipe Contreras

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Mailing List Archive on

Archives are clonable:
	git clone --mirror git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ \
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone