Re: How do I resolve conflict after popping stash without adding the file to index?

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> Right, I am suggesting that latter: that stash should abort if the index
> has modified entries. The abort for modified working tree files is done
> by git-merge, which can be selective about which entries will be changed
> (since it knows which ones need written).  I haven't thought hard enough
> to say whether it should be doing the same for the index (i.e., whether
> this is a "merge" problem or a "stash" problem).

This is a stash problem.  I've always thought that it insisted on
having a clean index and a clean working tree, but apparently it
doesn't, as shown in Dmitry's example sequence.

Generally speaking, any mergy operation should be done with a clean
index (i.e. matches HEAD) so that any difference between the index
and the HEAD after it stops in the middle is purely the result of
that mergy operation, and the commands should stop when the index is
not clean as a safety measure (e.g. "git am -3", "git merge") [*1*].

An especially tricky command may also insist on a clean working tree
if it is not easy to guarantee that it will not clobber changes by
the user when it stops in the middle (e.g. "git rebase").  But this
is an escape hatch for lazy implementations ;-) It would be ideal if
a command stops without doing anything when the set of paths it
needs to touch would overlap the set of paths in which user has
changes before the command is run (e.g. "git merge" works that way).

I think that "stash apply" requires a clean working tree for the
latter reason, and does not require a clean index because it just
forgot that it must do so.