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

From: Øystein Walle <[email-masked]>
Date: Wed, 8 Jan 2014 00:03:54 +0000 (UTC)

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

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