Re: [PATCH v3] Add core.mode configuration

Krzysztof Mazur wrote:

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).

If we have both, and the user sets core.mode = next, that means the user wants
*all* the incompatible changes.

But if another git v2.0 incompatible change will be added it will not
be warned, because with core.mode=next he decided to enable also
future changes and that's why I would never set that.

That's fine, you wouldn't set that, but I would. That's why it's a
configuration.

quoted

quoted

I think it's better to keep the old behavior by default and warn the user if
with new behavior the result might be different. So the user:

	a) knows about the change

	b) may set appropriate option to enable the new default or keep
	   the old behavior and disable the warning

	c) may report that he does not like that change

But that's what we are doing already. Look at the test I wrote, it's testing
the warnings for the current version of Git.

With pull.default we did that, but with git add v2.0 now we only warn
the user. With your patch he can enable new git add (and disable warning),
but he also enables future incompatible changes and disables
warnings for such changes.

Yeah, but I suggested to have *both* a fine-tunned option and a general one,
didn't I?

He also cannot keep the old behaviour and disable the warning.

He cannot do that regardless if my patch is merged or not.

quoted

quoted

I don't see the change in "git add" as an improvement, because
removing files with "git add" IMHO is more confusing than ignoring
such files. Maybe introducing new command - "git update" for instance -
which is equivalent to new "git add" and teaching new users to use it
instead of "git add" is better.

I agree. At first I simply ignored the changes because I didn't have the
patience to figure out what exactly did they mean. Now I was forced to
understand them to write this patch, and I'm also forcing myself to use this
behavior.

'git add' removing files is counter-intutive, 'git stage' (currently an alias
to 'git add') might make more sense.

Yeah, 'git stage' as an alias to 'git add -A' is much more intuitive.

Agreed.

-- 
Felipe Contreras