So, I read through git-stash.sh a little more, and found the following: 1. Any stash that can be shown can be applied, but not necessarily popped or dropped (as the documentation indicates). The reason for this is simple: a pop/drop attempts to clear the entry in the stash reflog as well, but all stashes need to have a corresponding reflog entry (for instance, those created with 'stash create'). 2. IS_STASH_LIKE is a misnomer: all it checks is that the given <rev> is a merge commit. As a result, you can 'stash show' and 'stash apply' any merge commit. Should we attempt to tighten this somehow, or are we okay with the stash being just another merge commit? Check for a special commit message perhaps? Brandon Casey wrote: > You can create a stash without modifying the refs/stash reflog using > 'sha1=`git stash create`' and then later apply it using 'git stash > apply --index $sha1'. You'll have to reset the work directory > yourself though since 'git stash create' does not do so. The stash > created this way is just a dangling commit so it will have a lifetime > according to the gc.pruneexpire (default 2 weeks currently). Thanks, but I was worried more about reachability of the commit: if I create a ref to it in refs/stashes/* like I suggested, it wouldn't expire until that ref was gone. Then again, I suppose a ref is unnecessary for a temporary stash. Yeah, I can store the SHA-1 hex of the dangling commit in my caller's $state_dir, and apply it from there later. -- 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