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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to