Jonathan Nieder wrote:
> Philip Oakley wrote:
>
> > 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
--
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
