Re: [PATCH v3] Add core.mode configuration

Jonathan Nieder wrote:

Philip Oakley wrote:

quoted

Would this be a good time to suggest a specific wording should be
proposed (or a reminder of what was proposed repeated) for the
documentation of this option. It will be the documentation that
users will refer to when they need to know, rather than the list
discussions.

It's not clear to me that this config item is a good idea.

What is the intended use?  If someone wants to test that their scripts
will continue to work with git 2.0, wouldn't testing a 2.0 release
candidate

There is no 2.0 release candidate, and the window between the first 2.0 rc and
2.0 final is limited, such person might not have the time do such testing in
that window.

Moreover, it's not just to test their scripts, but also their fingers.

(or the current state of the 'jch' branch until one exists)

That doesn't work for the vast majority of users who do not compile Git.

If someone just likes the proposed behavior changes and wants to start using
them right away, maybe we can help them by releasing 2.0 sooner ;-)

So basically you are advocating for another v1.6 fiasco, where users start
complaining about the new behaviors *after* the release has been made, and
their user experience has been broken. Is that the case?

, or by advertising the
fairly simple changes in commandline usage to get the new behaviors:

	Instead of "git add", use "git add -A".

	When using "git add -u" or "git add -A" from a subdirectory
	of the toplevel, specify "git add -u ." explicitly unless you
	want it to apply to the whole tree (in which case use
	"git add -u :/").

	Instead of letting "git push" guess, name the branch you
	want to push: "git push origin master".  Or set
	'[push] default = simple' in your configuration.

	Pass --prefix to "git svn clone".

I don't get why you don't understand something so simple about human nature.
Every teach knows that you don't just give a lecture, even if the student
understands what you explained, most likely (s)he would not learn it until
after doing excercises.

99% of our users have not read the release notes about the 2.0 changes, 98%
will not read that advertizement you just said, 90% of those who read it will
only get noise, and the ones that read and understand it, might change their
minds once they experience it.

That's why in every game conference they don't just explain to you the new
game, they let you play it, only then the end users can give an honest opinion
about the game.

Perhaps it's unfortunate, but our users are human, and that's how humans work.

We don't know if our users would be OK with the 2.0 changes, it's only after
they have given it a try that they can honestly say, and it's better to give
them as much time as possible and make it easier for them to try.

The downside of configuration like the proposed core.next is that it
is hard to explain ("What do you mean that I can't roll back to the
pre-2.0 behavior in Git 2.0 by setting this configuration setting to
an appropriate value?"),

It is not hard to explain.

core.mode = next enables the proposed behavior for the next major version of
Git (v2.0), which might change. core.mode = current (the default) enables the
behavior of the current version of Git (v1.x).

It is implied that there's no core.mode = previous, but it can be explicitly stated.

users or scripts can rely on it, and configuration variables tend to
accumulate and never be removed.

Not this one, because this one makes it clear that is volatile (although
probably not that much).

If we really want a run-time switch for this, I suspect an appropriately
named environment variable would work better, since we have a history of
being able to remove those without alarming people.

The fact that B has done the job in the past, doesn't mean it would do the job
better than A in the future.

-- 
Felipe Contreras