Re: [PATCH v3] Add core.mode configuration

John Szakmeister wrote:

On Tue, Oct 15, 2013 at 10:51 AM, Krzysztof Mazur [off-list ref] wrote:

quoted

On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote:

quoted

Krzysztof Mazur wrote:

quoted

On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:

quoted

Krzysztof Mazur wrote:

quoted

But with core.mode = next after upgrade you may experience incompatible
change without any warning.

Yes, and that is actually what the user wants. I mean, why would the user set
core.mode=next, if the user doesn't want to experencie incompatible changes? A
user that sets this mode is expecting incompatible changes, and will be willing
to test them, and report back if there's any problem with them.

With your patch, because it's the only way to have 'git add' v2.0.

Yeah, but that's not what I'm suggesting. I suggested to have *both* a
fined-tunned way to have this behavior, say core.addremove = true, and a way to
enable *all* v2.0 behaviors (core.mode = next).

I'm just not sure if a lot of users would use core.mode=next, because
of possible different behavior without any warning. Maybe we should also
add core.mode=next-warn that changes defaults like next but keeps warnings
enabled until the user accepts that change by setting appropriate
config option? That's safer than next (at least for interactive use) and
maybe more users would use that, but I don't think that's worth adding.

I like the idea that we could kick git into a mode that applies the
behaviors we're talking about having in 2.0, but I'm concerned about
one aspect of it.  Not having these behaviors until 2.0 hits means
we're free to renege on our decisions in favor of something better, or
to pull out a bad idea.  But once we insert this knob, I don't know
that we have the same ability.  Once people realize it's there and
start using it, it gets harder to back out.  I guess we could maintain
the stance that "the features are not concrete yet," or something like
that, but I think people would still get upset if something changes
out from under them.

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.

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.

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

-- 
Felipe Contreras