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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
