* [PATCH] peel_onion(): add support for <rev>^{tag}
@ 2013-06-19 1:39 Richard Hansen
2013-06-19 18:38 ` Junio C Hamano
2013-06-20 17:14 ` Ramkumar Ramachandra
0 siblings, 2 replies; 5+ messages in thread
From: Richard Hansen @ 2013-06-19 1:39 UTC (permalink / raw)
To: git; +Cc: Richard Hansen
gitrevisions(7) implies that <rev>^{tag} should work, but before now
it did not:
$ git rev-parse --verify v1.8.3.1^{tag}
fatal: Needed a single revision
This commit fixes the omission:
$ git rev-parse --verify v1.8.3.1^{tag}
4bc068950abec778a02ebf3ee73cf0735affabb4
Other object type names work as expected:
$ git rev-parse --verify v1.8.3.1^{commit}
362de916c06521205276acb7f51c99f47db94727
$ git rev-parse --verify v1.8.3.1^{tree}
c1fef48675edd74e9af19405339e8bdaebd56b0c
$ git rev-parse --verify v1.8.3.1^{blob}
error: v1.8.3.1^{blob}: expected blob type, but the object dereferences to tree type
fatal: Needed a single revision
Note that <rev>^{tag} is not the same as <rev>^{object} when <rev> is
not a tag:
$ git rev-parse --verify v1.8.3.1^{}^{object}
362de916c06521205276acb7f51c99f47db94727
$ git rev-parse --verify v1.8.3.1^{}^{tag}
error: v1.8.3.1^{}^{tag}: expected tag type, but the object dereferences to tree type
fatal: Needed a single revision
Signed-off-by: Richard Hansen <rhansen@bbn•com>
---
sha1_name.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sha1_name.c b/sha1_name.c
index 90419ef..68fd0e4 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -677,6 +677,8 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)
sp++; /* beginning of type name, or closing brace for empty */
if (!strncmp(commit_type, sp, 6) && sp[6] == '}')
expected_type = OBJ_COMMIT;
+ else if (!strncmp(tag_type, sp, 3) && sp[3] == '}')
+ expected_type = OBJ_TAG;
else if (!strncmp(tree_type, sp, 4) && sp[4] == '}')
expected_type = OBJ_TREE;
else if (!strncmp(blob_type, sp, 4) && sp[4] == '}')
--
1.8.3.1
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH] peel_onion(): add support for <rev>^{tag} 2013-06-19 1:39 [PATCH] peel_onion(): add support for <rev>^{tag} Richard Hansen @ 2013-06-19 18:38 ` Junio C Hamano 2013-06-19 20:08 ` Richard Hansen 2013-06-20 17:14 ` Ramkumar Ramachandra 1 sibling, 1 reply; 5+ messages in thread From: Junio C Hamano @ 2013-06-19 18:38 UTC (permalink / raw) To: Richard Hansen; +Cc: git Richard Hansen <rhansen@bbn•com> writes: > gitrevisions(7) implies that <rev>^{tag} should work,... Does it? Is it possible that that should be fixed? What does it even _mean_ to peel something to a TAG? A commit, a tree or a blob cannot be peeled to a tag---none of them can contain a tag. When you have a tag that points at something else, what you have is already a tag, so <that-tag>^{tag} would be <that-tag> itself. Even more confusingly, when you have a tag that points at another tag, what does <that-outer-tag>^{tag} mean? The outer tag itself, or do you need to peel at least once to reveal the inner-tag? What if that inner-tag points at yet another tag? The patch does not touch peel_to_type(), so your answer to the above question seems to be "if T is already a tag, T^{tag} is T itself", but then that operation does not look all that useful. Confused... > diff --git a/sha1_name.c b/sha1_name.c > index 90419ef..68fd0e4 100644 > --- a/sha1_name.c > +++ b/sha1_name.c > @@ -677,6 +677,8 @@ static int peel_onion(const char *name, int len, unsigned char *sha1) > sp++; /* beginning of type name, or closing brace for empty */ > if (!strncmp(commit_type, sp, 6) && sp[6] == '}') > expected_type = OBJ_COMMIT; > + else if (!strncmp(tag_type, sp, 3) && sp[3] == '}') > + expected_type = OBJ_TAG; > else if (!strncmp(tree_type, sp, 4) && sp[4] == '}') > expected_type = OBJ_TREE; > else if (!strncmp(blob_type, sp, 4) && sp[4] == '}') ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] peel_onion(): add support for <rev>^{tag} 2013-06-19 18:38 ` Junio C Hamano @ 2013-06-19 20:08 ` Richard Hansen 2013-06-20 18:03 ` Junio C Hamano 0 siblings, 1 reply; 5+ messages in thread From: Richard Hansen @ 2013-06-19 20:08 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On 2013-06-19 14:38, Junio C Hamano wrote: > Richard Hansen <rhansen@bbn•com> writes: > >> gitrevisions(7) implies that <rev>^{tag} should work,... > > Does it? Is it possible that that should be fixed? Depends on whether you think ^{tag} is a useful feature or not; see below. > > What does it even _mean_ to peel something to a TAG? It's the same as peeling something to any other object type: If the object is that type, done. Otherwise dereference and try again. If it can't be dereferenced, barf. > > A commit, a tree or a blob cannot be peeled to a tag---none of them > can contain a tag. Right, so all of those would barf. > > When you have a tag that points at something else, what you have is > already a tag, so <that-tag>^{tag} would be <that-tag> itself. Exactly, just like <object>^{object} is <object> itself. > > Even more confusingly, when you have a tag that points at another > tag, what does <that-outer-tag>^{tag} mean? The outer tag itself, > or do you need to peel at least once to reveal the inner-tag? What > if that inner-tag points at yet another tag? > > The patch does not touch peel_to_type(), so your answer to the above > question seems to be "if T is already a tag, T^{tag} is T itself", > but then that operation does not look all that useful. Barfing on non-tags is the feature this adds. It's otherwise useless, just like <object>^{object} is useless except to barf when <object> doesn't exist. It's a sometimes-convenient way to assert that an object specifier refers to a tag object and not something else. For example, instead of: fatal() { printf %s\\n "ERROR: $*" >&2; exit 1; } type=$(git cat-file -t "$1") || fatal "$1 is not a valid object" [ "${type}" = tag ] || fatal "$1 is not a tag object" use "$1" here you can do: use "$1"^{tag} here -Richard > > Confused... > >> diff --git a/sha1_name.c b/sha1_name.c >> index 90419ef..68fd0e4 100644 >> --- a/sha1_name.c >> +++ b/sha1_name.c >> @@ -677,6 +677,8 @@ static int peel_onion(const char *name, int len, unsigned char *sha1) >> sp++; /* beginning of type name, or closing brace for empty */ >> if (!strncmp(commit_type, sp, 6) && sp[6] == '}') >> expected_type = OBJ_COMMIT; >> + else if (!strncmp(tag_type, sp, 3) && sp[3] == '}') >> + expected_type = OBJ_TAG; >> else if (!strncmp(tree_type, sp, 4) && sp[4] == '}') >> expected_type = OBJ_TREE; >> else if (!strncmp(blob_type, sp, 4) && sp[4] == '}') > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] peel_onion(): add support for <rev>^{tag} 2013-06-19 20:08 ` Richard Hansen @ 2013-06-20 18:03 ` Junio C Hamano 0 siblings, 0 replies; 5+ messages in thread From: Junio C Hamano @ 2013-06-20 18:03 UTC (permalink / raw) To: Richard Hansen; +Cc: git Richard Hansen <rhansen@bbn•com> writes: > Barfing on non-tags is the feature this adds. It's otherwise useless, > just like <object>^{object} is useless except to barf when <object> > doesn't exist. Thanks. I could buy that. And after re-reading the proposed log message, you do not quite have anything to say that. Instead, you have this: Note that <rev>^{tag} is not the same as <rev>^{object} when <rev> is not a tag: $ git rev-parse --verify v1.8.3.1^{}^{object} 362de916c06521205276acb7f51c99f47db94727 $ git rev-parse --verify v1.8.3.1^{}^{tag} error: v1.8.3.1^{}^{tag}: expected tag type, but the object deref... fatal: Needed a single revision The latter peels v1.8.3.1 to a non-tag (i.e. a commit) and then asks to peel that commit to a tag, which will of course fail, but that is not a good example. Perhaps something like this instead. Note that <rev>^{tag} can be used to make sure <rev> names a tag: $ git rev-parse --verify v1.8.3.1^{tag} $ git rev-parse --verify master^{tag} The former succeeds, while the latter fails. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] peel_onion(): add support for <rev>^{tag} 2013-06-19 1:39 [PATCH] peel_onion(): add support for <rev>^{tag} Richard Hansen 2013-06-19 18:38 ` Junio C Hamano @ 2013-06-20 17:14 ` Ramkumar Ramachandra 1 sibling, 0 replies; 5+ messages in thread From: Ramkumar Ramachandra @ 2013-06-20 17:14 UTC (permalink / raw) To: Richard Hansen; +Cc: git Richard Hansen wrote: > --- a/sha1_name.c > +++ b/sha1_name.c > @@ -677,6 +677,8 @@ static int peel_onion(const char *name, int len, unsigned char *sha1) > sp++; /* beginning of type name, or closing brace for empty */ > if (!strncmp(commit_type, sp, 6) && sp[6] == '}') > expected_type = OBJ_COMMIT; > + else if (!strncmp(tag_type, sp, 3) && sp[3] == '}') > + expected_type = OBJ_TAG; Interesting. > gitrevisions(7) implies that <rev>^{tag} should work, but before now > it did not: The wording (especially of <rev>^{}) special-cases tags as "objects to dereference". > $ git rev-parse --verify v1.8.3.1^{}^{object} > 362de916c06521205276acb7f51c99f47db94727 > $ git rev-parse --verify v1.8.3.1^{}^{tag} > error: v1.8.3.1^{}^{tag}: expected tag type, but the object dereferences to tree type > fatal: Needed a single revision And the points out the problem: while ^{object} means "expect OBJ_ANY", ^{} means "expect OBJ_NONE". What does that even mean? See sha1_name.c:704 where this is handled sneakily: it just calls deref_tag(), bypassing peel_to_type() altogether. If anything, ^{} is already a poor-man's version of your ^{tag}; the reason it's a poor-man's version is precisely because it doesn't error out when <rev> isn't a tag, while your ^{tag} does. I would argue that ^{} is very poorly done and must be deprecated in favor of your ^{tag}. What is the point of using ^{} if you can't even be sure that what you get is a deref? peel_to_type() already does the right thing by not using deref_tag(), and explicitly checking. Your commit message needs some tweaking, but I'm happy with your patch otherwise. Thanks. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-06-20 18:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-19 1:39 [PATCH] peel_onion(): add support for <rev>^{tag} Richard Hansen
2013-06-19 18:38 ` Junio C Hamano
2013-06-19 20:08 ` Richard Hansen
2013-06-20 18:03 ` Junio C Hamano
2013-06-20 17:14 ` Ramkumar Ramachandra
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox