Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 17, 2013, 08:31 UTC
Message-ID: <CALkWK0kJOSBN8XTJKBLOqi4tUjjm9unr=No65TtW9V0qvKmV-A@mail.gmail.com>
In-Reply-To: <CA+sFfMd-pfmPXNCoAfH59om1cdYh1=bJ7yb-BGZHjkra5Gm_uw@mail.gmail.com>

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:

Show 6 quoted lines

> 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.