Revert "stash: require a clean index to apply"
commit19376104a8251a7e6c56579cdcd2eb0a106d1fd6
authorJeff King <peff@peff.net>
Mon, 15 Jun 2015 18:27:22 +0000 (15 14:27 -0400)
committerJunio C Hamano <gitster@pobox.com>
Mon, 15 Jun 2015 20:11:17 +0000 (15 13:11 -0700)
tree556c2836d2a935bd743dbca50a8b84fef05130ae
parented178ef13a26136d86ff4e33bb7b1afb5033f908
Revert "stash: require a clean index to apply"

This reverts commit ed178ef13a26136d86ff4e33bb7b1afb5033f908.

That commit was an attempt to improve the safety of applying
a stash, because the application process may create
conflicted index entries, after which it is hard to restore
the original index state.

Unfortunately, this hurts some common workflows around "git
stash -k", like:

    git add -p       ;# (1) stage set of proposed changes
    git stash -k     ;# (2) get rid of everything else
    make test        ;# (3) make sure proposal is reasonable
    git stash apply  ;# (4) restore original working tree

If you "git commit" between steps (3) and (4), then this
just works. However, if these steps are part of a pre-commit
hook, you don't have that opportunity (you have to restore
the original state regardless of whether the tests passed or
failed).

It's possible that we could provide better tools for this
sort of workflow. In particular, even before ed178ef, it
could fail with a conflict if there were conflicting hunks
in the working tree and index (since the "stash -k" puts the
index version into the working tree, and we then attempt to
apply the differences between HEAD and the old working tree
on top of that). But the fact remains that people have been
using it happily for a while, and the safety provided by
ed178ef is simply not that great. Let's revert it for now.
In the long run, people can work on improving stash for this
sort of workflow, but the safety tradeoff is not worth it in
the meantime.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-stash.sh
t/t3903-stash.sh