Re: [PATCH 1/5] t1508 (at-combinations): more tests; document failures
- From
Ramkumar Ramachandra <artagnon@gmail.com>
- Date
- May 1, 2013, 21:04 UTC
- Message-ID
- <CALkWK0nL+UvjsUKh6v4x_MaWJmsU6Uh_gh82iE7UT0UE-ZMt0g@mail.gmail.com>
- In-Reply-To
- <7va9oe5y6k.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 5 quoted lines
> Just making sure. HEAD@{$n} and @{$n} for non-negative $n mean
> totally different things. @{0} and HEAD@{0} are almost always the
> same, and @{1} and HEAD@{1} may often happen to be the same, but as
> a blanket statement, I find "Since HEAD is implicit in @{}" very
> misleading.When will they be different? I'm looking at this from the parser's point of view: when the part before @{} is missing, we dwim a "HEAD".
> As you and Felipe seem to be aiming for the same "Let's allow users > to say '@' when they mean HEAD", I'll let you two figure the best > approach out.
I've solved the problem in the general case of symbolic-refs and made "@" a special case of that.
> One productive way forward might be to come up with a common test > script pieces to document what constructs that spell @ in place of > HEAD should be supported,
It's sufficient to test that symbolic refs work properly. @ is a trivial implementation of a pseudo symbolic-ref (see [5/5]).
> and much more importantly, what constructs > that happen to have @ in them should not mistakenly trigger the new > machinery.
At the parsing level, @ can only ever interfere with @{}; I've added tests for those.