[PATCH 0/5] A natural solution to the @ -> HEAD problem

[Ramkumar Ramachandra <artagnon@gmail.com>]

Hi,

Felipe's approach to solving the problem is a recursive reinterpret()
that relies on parsing the sequence @[^{].  Seems like quite a
contrived hack, and I think we can do much better than this.

Here, I present my approach to solving the problem.  It interprets @
just like a ref in resolve_ref_unsafe(), after everything else has
been peeled off; the solution is just the few simple lines shown in
[5/5].

The core of the series tackles refactoring the @-parsing so that [5/5]
becomes possible without doing anything contrived.  [1/5] introduces
the problem I started solving: making symbolic refs work properly.
[2/5] and [3/5] are a result of me reading through the horrible
@-parsing code.  [4/5] finally solves the symbolic ref problem, and
[5/5] becomes trivial.

A side-effect of the series is that you can now do:

    $ git symbolic-ref H HEAD
    $ git show H@{u}

In other words, symbolic refs actually work now and you can use them
to achieve a lot of custom overrides.  I think it is a step in the
right direction.

Thanks for listening, and hope you enjoy reading the series as much as
I enjoyed writing it.

Ramkumar Ramachandra (5):
  t1508 (at-combinations): more tests; document failures
  sha1_name.c: don't waste cycles in the @-parsing loop
  sha1_name.c: simplify @-parsing in get_sha1_basic()
  remote.c: teach branch_get() to treat symrefs other than HEAD
  refs.c: make @ a pseudo-ref alias to HEAD

 Documentation/git-check-ref-format.txt |  2 +
 Documentation/revisions.txt            |  8 +++-
 refs.c                                 | 12 ++++-
 remote.c                               | 14 ++++++
 sha1_name.c                            | 85 +++++++++++++++++++++++++---------
 t/t1400-update-ref.sh                  |  3 ++
 t/t1508-at-combinations.sh             | 15 ++++++
 7 files changed, 113 insertions(+), 26 deletions(-)

-- 
1.8.3.rc0.24.g6456091