Re: [PATCH] Make "git stash" configurable

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 21, 2007, 19:48 UTC
Message-ID: <7vmys36d7n.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <2AB285BD-DA6E-49D1-B664-B1A8B552DD76@midwinter.com>

Steven Grimm <koreth@midwinter.com> writes:

Show 8 quoted lines

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