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

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

Thomas Rast <tr <at> thomasrast.ch> writes:

quoted

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

quoted

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