On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote:
> Krzysztof Mazur wrote:
> > On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:
> > > Krzysztof Mazur wrote:
> > > > 
> > > > 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.

For me, old behavior by default and warnings with information how to
enable new incompatible features, is sufficient. So I don't need
core.mode option, but as long it will be useful for other users I have
nothing against it.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to