t1508 (at-combinations): more tests; document failures

To emphasize what we're testing in @{1}@{u}, document that @{0}@{0} is
also nonsense.  This makes it clear that @{<n>} does not resolve to a
ref whose upstream we can determine with @{u}/ reflog we can dig with
@{0}.

Since HEAD is implicit in @{}, check that HEAD@{} works fine for these
cases.  It doesn't make sense in @{-<n>} because @{-<n>} cannot be
used with anything other than HEAD, and interpret_nth_prior_checkout()
hard-codes "HEAD".

Additionally, document bugs in the @-parser by symbolic-ref'ing @ to
HEAD and re-running some tests.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
sha1_name.c: don't waste cycles in the @-parsing loop

The @-parsing loop unnecessarily checks for the sequence "@{" from
len - 2 unnecessarily.  We can safely check from len - 4: write out a
comment justifying this.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
sha1_name.c: redo @-parsing in get_sha1_basic()

Presently, the logic for @-parsing is horribly convoluted.  Prove that
it is very straightforward by laying out the three cases (@{N},
@{u[upstream], and @{-N}) and explaining how each case should be
handled in comments.  All tests pass, and no functional changes have
been introduced.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
remote.c: teach branch_get() to treat symrefs other than HEAD

Currently, branch_get() either accepts either a branch name, empty
string, or the magic four-letter word "HEAD".  Make it additionally
handle symbolic refs that point to a branch.

Update sha1_name.c:interpret_branch_name() to look for "@{", not '@'
(since '@' is a valid symbolic ref).

These two changes together make the failing test in t1508
(at-combinations) pass.  In other words, you can now do:

    $ git symbolic-ref @ HEAD

And expect the following to work:

    $ git rev-parse @@{u}

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
refs.c: make @ a pseudo-ref alias to HEAD

First, make sure that check_refname_format() rejects the a refname
beginning with a '@'.  Add a test to t1400 (update-ref) demonstrating
that update-ref forbids the user from updating a ref named "@".

Now, resolve_ref_unsafe() is built to resolve any refs that have a
corresponding file inside $GITDIR.  Our "@" ref is a special
pseudo-ref and does not have a filesystem counterpart.  So,
hard-interpret "@" as "HEAD" and resolve .git/HEAD as usual.  This
means that we can drop the 'git symbolic-ref @ HEAD' line in t1508
(at-combinations), and everything will continue working as usual.

If the user does manage to create a '.git/@' unsafely (via
symbolic-ref or otherwise), it will be ignored.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>