Jeff King <p...@peff.net> writes:
> Ironically, the message before e0e2a9c actually recommends staging
> changes before applying the stash, which would lead to this exact
> situation!
The ancient history is hazy to me, but did we fall back to three-way
merge in old days (or did anything to the index for that matter), I
wonder? In a world "git stash apply" only applied the change to the
working tree via "git apply", that old recommendation would make
perfect sense.
But obviously we do not live in such a world right now. And because
we are doing "merge-recursive", we should insist on a clean index;
otherwise there is no way to "undo" its effect without losing the
changes by the end-user.
> So I think the most trivial patch is:
>
> diff --git a/git-stash.sh b/git-stash.sh
> index d4cf818..f1865c9 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -442,6 +442,7 @@ apply_stash () {
> assert_stash_like "$@"
>
> git update-index -q --refresh || die "$(gettext "unable to refresh
> index")"
> + git diff-index --cached HEAD || die "dirty index; cannot apply stash"
Yes, that makes sense. The original report from Dmitry was
triggering the safety from one line above and "git stash pop" doing
the right thing by refusing to touch the index with unresolved mergy
operation before doing anything, and with this additional safety, we
would make it even safer from people who do "git add" and then "git
stash pop" (which is somewhat strange thing to do, given that
"stash" was designed for "stash to save away; do other things; come
back to the original commit state that is 'reset --hard' clean;
unstash" sequence in the first place).
> # current index state
> c_tree=$(git write-tree) ||
>
> but it makes me wonder if somebody would find it annoying that they
> cannot apply a stash into their work-in-progress (i.e., it _might_ cause
> annoyance, but most of the time it will be convenient to do so).
They can always do "git stash show -p stash@{n} | git apply" if they
want to build changes incrementally X-<, but it would be annoying.
> So probably we'd want to refactor that into two separate functions, and
> only call the require_clean_index part.
Hmph, but what would that helper do, other than a single "diff-index
--quiet --cached HEAD" call?
--
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
