Thread (25 messages) flat view 25 messages, 5 authors, 2016-06-15

Re: [PATCH v3] Add core.mode configuration

From: Krzysztof Mazur <hidden>
Date: 2016-06-15 22:59:01

On Tue, Oct 15, 2013 at 10:55:07PM -0500, Felipe Contreras wrote:
John Szakmeister wrote:
quoted
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.
If we add core.addremove=true the same applies to it - we cannot remove
it later, the only we can do is to disable it by default in future
versions after testing (core.addremove=true or core.mode=next).
quoted
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.
BTW, I'm still using pre-1.6 git-foo, I have /usr/libexec/git-core
in my PATH. So I would like to always have an option to disable some
new incompatible "improvements".
So I say we shouldn't just provide warnings, but also have an option to allow
users (probably a minority) to start testing this.
and an option to keep the old behavior, like we did with push.default.

Krzysiek
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help