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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 16, 2013, 18:41 UTC
Message-ID: <7vmwsyl3mv.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1366135765-18437-1-git-send-email-artagnon@gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 20 quoted lines

> 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 <artagnon@gmail.com>
> ---
>  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.