Re: [PATCH v3] stash: handle specifying stashes with spaces

From: Øystein Walle <oystwa@gmail.com>
Date: Jan 8, 2014, 00:03 UTC
Message-ID: <loom.20140108T003945-67@post.gmane.org>
In-Reply-To: <xmqqiotvbf4g.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster <at> pobox.com> writes:

Show 21 quoted lines

> 
> Thomas Rast <tr <at> thomasrast.ch> writes:
> 
> > Junio C Hamano <gitster <at> pobox.com> writes:
> >
> >>
> >> This is brittle.  If new tests are added before this, the test_tick
> >> will give you different timestamp and this test will start failing.
> >>
> >> Perhaps grab the timestamp out of the stash that was created [...]
> >
> > Hmm, now that I stare at this, why not simply use something like
> >
> >   git stash apply "stash <at> { 0 }"
> >
> > It seems to refer to the same as stash <at> {0} as one would expect, while
> > still triggering the bug with unpatched git-stash.
> 
> Yeah, that is fine as well.  For the record, here is what I
> tentatively queued.
>

I completely agree that it's brittle. I mentioned it when I submitted v1 but at the time it didn't occur to me that new tests might be added before it. And of course I agree with your proposed changes to the test. I must say I like Thomas' solution because of its simplicity and the whole test could be made much shorter: just create stash and try to pop it.

But it's seems the spaces trigger some other way of interpreting the selector. In my git.git, git rev-parse HEAD{0} gives me the same result as HEAD@{ 0 } but HEAD@{1} and HEAD@{ 1 } are different. Is this intentional? If not, can this impact the reliability of the test if we use HEAD@{ 0 } ?

Thanks for queuing!

Regards, Øsse