Steven Grimm <koreth@xxxxxxxxxxxxx> writes:
> On Dec 21, 2007, at 2:22 AM, しらいしななこ wrote:
>
>> "git stash" without argument originally created an unnamed
>> stash, but some people felt this can be confusing to new
>> users. This introduces per-user config variable stash.quick to
>> control this behavior.
>
> This whole thing smells of indecision to me.
If you want to force me to decide, you know what the decision it
would be. Here are the guiding principles and decisions based
on them.
(1) A tool should be optimized for people who know what it does
and how to use it.
While forbidding "git stash" without argument and forcing
people who want to have a quick stash to type "git stash
save" may appear not to be adding too many keystrokes, it
actually is a regression. Because "git stash save" without
arguments make a much less descriptive stash than the
current quickie "git stash", doing so slows them down by
forcing them to think of what message to give.
The decision would be to keep "git stash" quickie stash
creation. An alternative decision could be to do nothing
when "git stash" is given, and make "git stash save" (and
"git stash create") without the actual message to come up
with a better default message.
(2) A tool should not change its behaviour too drastically
depending on who the user is.
Otherwise it makes it harder for people with mid-level
experience to teach less experienced people. The decision
would be that "stash.quick=ask" and "stash.quick=no" are
unacceptable.
(3) A tool should support safety for a mistaken use by who know
the tool (even they can make mistakes).
I listed this mostly because we made "git clean" to violate
principle (2) above. Even when you know what that command
does, it is easy to mean "make clean" and type "git clean"
by mistake. And "git clean" is very destructive --- there
is no "oops, I take it back". This principle has led us to
introduce clean.requireforce that defaults to true.
For "git stash", there is no "make stash" or "xyzzy stash"
that can easily induce mistyping. Even if it were typed by
mistake, there is no such destructive "oops, I cannot take
it back" problem with "git stash", either. "git stash
apply" will get you back to where you were. The decision
would again be that "stash.quick=no" is unwanted.
(4) A tool should support safety for clueless people when it is
reasonable.
Even though "I did not know what command foo does, so I
tried running it and it did something unexpected" is a
silly excuse to rob quickie "git stash" from people who
know better, we cannot avoid the fact that there are
clueless people. I think checking stash.iknowwhatitdoes to
detect first-time users, and explaining what it does to
them, may make sense. And we can take hints from the patch
that started this thread how to do this.
The decision here is that I am open to a change that
implements the one-time safety instruction.
Note that in the above guiding principles, I used "should" in
RFC2119/BCP0014 sense: there may exist valid reasons in
particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed
before choosing a different course.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
