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

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(-)