v4peel_onion(): add support for <rev>^{tag}

Complete the <rev>^{<type>} family of object descriptors by having <rev>^{tag} dereference <rev> until a tag object is found (or fail if unable).

At first glance this may not seem very useful, as commits, trees, and blobs cannot be peeled to a tag, and a tag would just peel to itself. However, this can be used to ensure that <rev> names a tag object:

    $ git rev-parse --verify v1.8.4^{tag}
    04f013dc38d7512eadb915eba22efc414f18b869
    $ git rev-parse --verify master^{tag}
    error: master^{tag}: expected tag type, but the object dereferences to tree type
    fatal: Needed a single revision

Users can already ensure that <rev> is a tag object by checking the
output of 'git cat-file -t <rev>', but:
  * users may expect <rev>^{tag} to exist given that <rev>^{commit},
    <rev>^{tree}, and <rev>^{blob} all exist
  * this syntax is more convenient/natural in some circumstances

Signed-off-by: Richard Hansen <rhansen@bbn.com>
---
Changes from v3 (2013-09-03, see
<http://thread.gmane.org/gmane.comp.version-control.git/233752>):
  * Use Peff's simpler test case.

 Documentation/revisions.txt | 3 +++
 sha1_name.c                 | 2 ++
 t/t1511-rev-parse-caret.sh  | 7 +++++++
 3 files changed, 12 insertions(+)

Richard Hansen <rhansen@bbn.com> writes:

Looks good to me.  Testing both failure case and success case.

Thanks; will queue.

When we are parsing "rev^{foo}", we check "foo" against the various global type strings, like "commit_type", "tree_type", etc. This is nicely abstracted, but then we destroy the abstraction completely by using magic numbers that must match the length of the type strings.

We can avoid these magic numbers by using skip_prefix. In an ideal world, the compiler would compute the magic number without even calling strlen() at runtime. However, it cannot do so in this case because we hide the definition of commit_type and friends behind an extern declaration.

This shouldn't matter, though, as this is not a performance critical code path. A few short strlens inside get_sha1() will not even be measurable. And if we care, we can adjust the declaration of commit_type and friends later on.

Signed-off-by: Jeff King <peff@peff.net>
---
This is the potential cleanup we discussed. Having written that commit
message, I wonder if it is really even worth using commit_type at all.
It is not like that variable can ever change without the git data
structure changing, and even if it did, we would almost certainly want
to revisit how that change affects the user-visible "rev^{}" syntax
anyway.

So maybe simply:

  if (!prefixcmp("commit}"))

would be fine, and it is way more readable. That's what we do already for "rev^{object}".

 sha1_name.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

When we are parsing "rev^{foo}", we check "foo" against the various global type strings, like "commit_type", "tree_type", etc. This is nicely abstracted, but then we destroy the abstraction completely by using magic numbers that must match the length of the type strings.

We could avoid these magic numbers by using skip_prefix. But taking a step back, we can realize that using the "commit_type" global is not really buying us anything. It is not ever going to change from being "commit" without causing severe breakage to existing uses. And even if it did change for some crazy reason, we would want to evaluate its effects on the "rev^{}" syntax, anyway.

Let's just switch these to using a custom string literal, as we do for "rev^{object}". The resulting code is more robust to changes in the type strings, and is more readable.

Signed-off-by: Jeff King <peff@peff.net>
---
If you _really_ wanted to abstract it, you could make commit_type a
macro and use string concatenation along with prefixcmp. But that is
going in the direction of less readable, I think. :)

This has probably consumed enough brain cycles for such a small and probably unimportant cleanup. I'll let Junio pick from the 2 options (or choose to do nothing at all) as he sees fit.

 sha1_name.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Jeff King <peff@peff.net> writes:

;-) we are on the same wave-length.

Thanks, will apply.