From: "Jonathan Nieder" <jrnie...@gmail.com>
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.
My point was that the arguments had been rehearsed and explored, and
that it was possibly a suitable time for Filippe to update any commit
message and config item documentation so that the proposal can be
judged.
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 (or the current state of the 'jch' branch until one exists)
be the simplest way to do that? 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 ;-), or by advertising the
fairly simple changes in commandline usage to get the new behaviors:
In terms of moving forward, there needs to be a balance between being
stuck in the old world of the 60's, and being projected into the bright
new world of the 20's (OK so I have exaggerated a bit there ;-). It's
always been a case of different strokes for different folks - there will
be folk who will try such an option (in an honest manner), who may not
be aware of branches that are outside of the regular pu / next / master
/ maint branches which the project publicises.
Rather than letting the email discussion degenerate by going round in
circles to the usual end point, having a clarifying proposal (hopefully
well balanced) would at least allow a cleaner understanding and
decision.
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".
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?"), users or scripts can rely on it, and
configuration variables tend to accumulate and never be removed. 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.
My two cents,
Jonathan
--
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
