Jeff King <peff@xxxxxxxx> 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. -- 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