Ramkumar Ramachandra <[email protected]> writes:
> While a 'git stash show stash^{/quuxery}' works just fine, a 'git
> stash pop stash^{/quuxery}' complains with: 'stash^{/quuxery} is not a
> stash reference'. This confusing behavior arises from the differences
> in logic that 'show' and 'pop' internally employ to validate the
> specified ref. Document this bug by adding a failing testcase for it.
>
> Signed-off-by: Ramkumar Ramachandra <[email protected]>
> ---
> So sorry about misspelling Junio's address in my previous email.
> Please respond to this one instead.
>
> So if you look at git-stash.sh:377, you'll notice that it's doing a
> the shell substitution "${REV%@*}" to figure out whether the stash
> ref is a valid ref. This hacky myopic design has to be done away
> with immediately, and we should really compare the SHA-1 hex of the
> specified ref with those in the stash reflog.
>
> The only reason I haven't written a fix yet is because I'm not sure
> why you need this convoluted IS_STASH_LIKE and IS_STASH_REF logic in
> the first place. Can someone enlighten me as to what is going on?
I think they were an attempt to catch command line argument errors
early to be helpful to the end users.
See ef763129d105 (detached-stash: introduce parse_flags_and_revs
function, 2010-08-21). As the advertised and originally intended
use for stash was to name them with "stash@{number}", chomping at
the first at-sign to make sure it names refs/stash does not sound
too bad a check.
I do not think anybody considered the approach to look at the commit
object name and making sure it appears in the reflog that implements
the stash. It sounds like a more robust check if done right.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
