El 20/12/2007, a las 23:31, Junio C Hamano escribió:
しらいしななこ <nanako3@xxxxxxxxxxxxxx> writes:
How about making this behavior configurable?
First, as a general principle, I'd like to avoid having commands that
changes their behaviour drastically depending on who the user is. It
makes it harder for people experienced a bit more than totally new to
help others. If they are truly experts and are familiar about the
configuration stash.quick, then they will be fine, but others would
say
"Well, it works for me -- 'git stash' itself won't stash but list.
Why
isn't it working for you, I don't know" and scratch head.
Although the patch is well-intentioned, I totally agree with Junio on
this point.
The solution here isn't configuration, but education. Some people have
already told how they've been burnt by doing an accidental stash, but
how many times does this have to happen to you before you learn your
lesson? Once? Twice if you are very unlucky?
And this is not a very painful lesson to learn, seeing as "git stash"
is not an inherently destructive operation. In 99% of cases there is
no risk of hard-to-reverse "damage". If you accidentally stash, you
can just unstash with "git stash apply". I already posted a two-line
patch which tells the user how to do this:
http://marc.info/?l=git&m=119799257404542&w=2
The 1% of cases in which "git stash apply" won't work is where the
user has unsaved changes in running editors at the time they do the
accidental stash. IMO, this is no justification to change the
behaviour of stash. Exactly the same is true of other commands that
alter the working tree; for example, what happens if you use "git
checkout" to switch to another branch when you have unsaved changes in
running editors? Are people suggesting that we should change the
behaviour of "git checkout" to warn the user that they should save any
unsaved changes before continuing and then hit "y"? I think that such
a thing would be absurd.
Cheers,
Wincent
-
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
