Re: [PATCH] peel_onion(): add support for ^{tag}

Richard Hansen writes: > Barfing on non-tags is the feature this adds. It's otherwise useless, > just like ^{object} is useless except to barf when > 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,

Re: [PATCH] peel_onion(): add support for ^{tag}

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] == '}') >

Re: [PATCH] peel_onion(): add support for ^{tag}

On 2013-06-19 14:38, Junio C Hamano wrote: > Richard Hansen writes: > >> gitrevisions(7) implies that ^{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

Re: [PATCH] peel_onion(): add support for ^{tag}

Richard Hansen writes: > gitrevisions(7) implies that ^{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

[PATCH] peel_onion(): add support for ^{tag}

gitrevisions(7) implies that ^{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