Jeff King <peff@xxxxxxxxxx> writes: > The same "robustness" comments for the save_work function apply > here. You probably do not want to restore on a dirty tree; the > intended use case is "stash away, pull, then restore", so I > think it is Ok to assume that you will only be restoring on a > clean state (and it would make the implementation simpler). > > So perhaps there is no broken case at all, and it was just a matter of > being overly conservative from the beginning. Perhaps. If we are going to treat this as another mergy operation, we should at least still make sure that the index is clean (i.e. "diff --cached" is empty), I think. -- 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