t1508 (at-combinations): increase coverage

Add more tests exercising documented functionality.

It is worth noting that HEAD@{-<n>} is senseless because @{-<n>}
cannot be used with anything other than HEAD anyway.

[fc: contribute a couple of tests]

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
t1508 (at-combinations): document @{N} versus HEAD@{N}

All the tests so far check that @{N} is the same as HEAD@{N} (for
positive N).  However, this is not always the case: write a couple of
tests for this.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
t1508 (at-combinations): test with symbolic refs

Symbolic refs don't work with @{u}.  Document this failure.  Also
create a symbolic-ref @ (which is a valid ref name), and test
everything with it to make sure that there is no bug in the @-parser.

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

Broadly, there are two ways to resolve a command-line argument.  The
first approach is to treat it as a revision and resolve it using the
revision-parsing mechanism get_sha1().  The other approach is to treat
it as a ref, and use a reduced mechanism like branch_get().

Compare and contrast the implementations of @{N} and @{u} in
sha1_name.c to see where exactly branch_get() is useful:

In <...>@{N}, the <...> is passed through dwim_log() which first calls
substitute_branch_name() and then resolve_ref_unsafe() on that.  The
resolved ref could be any ref (symbolic/ non-symbolic), and not just a
refs/heads/* ref (branch).

However, in the <...>@{u} case, the <...> can only be a ref/heads/*
ref or a symbolic ref pointing to a refs/heads/* ref.  It uses
branch_get() to find the relevant ref.

Unfortunately, branch_get() doesn't call resolve_ref_unsafe() on what
is passed to it at all.  Instead it hard-codes the special four-letter
word "HEAD" (which is resolved by read_config() which is called
first), and rejects any other symbolic ref.  This is a historical
mistake because of which some callers of branch_get() suffer.  To put
it another way, the commands that accept "HEAD" (and resolve it into a
branch) can benefit from accepting any other symbolic ref that
resolves to a branch.  For example, the following fail:

    $ git symbolic-ref M refs/heads/master
    $ git show M@{u}
    $ git branch -u ram/master M

This patch fixes branch_get() directly, making these work.

Notice that branch_get() calls read_config(), which in turn
preemptively calls resolve_ref_unsafe() on "HEAD", when the caller
might not even be requesting the current branch.  After copying out
two critical tasks that are required for make_remote() to work
properly:

    git_config(handle_config, NULL);
    alias_all_urls();

we can remove read_config() and call resolve_ref_unsafe() on the
argument that is passed ourselves.  HEAD is therefore not a special
case anymore.

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

Symbolic refs work in the general case, but making @ a symbolic-ref
doesn't work due to a parsing bug in interpret_branch_name().  Update
the function to parse "@{", not '@' (since '@' is a valid symbolic
ref).

This makes a 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.

In practice, this means that you will now be able to do:

    $ git show @~1
    $ git log @^2

Advertise these features in the tests and documentation.

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