feature "git tag -r" to show tags and commits they are pointing to

feature "git tag -r" to show tags and commits they are pointing to

[Eugene Sajine]

Hi,

Currently there is no way you can get the commits your tags are
pointing to by using git tag.
The only way i found is to use rev-parse (which is by the way not
supported by the bash_completion)

It seems reasonable to have upper level command like:

$ git tag -r

to output

v0.1  8794hke84f9e8h9ef9eh949793...
v0.2  jhkd934398e9f499f47w9789o97...

$ git tag -n -r

v0.1 "super message"     8794hke84f9e8h9ef9eh949793...
v0.2  "another message" jhkd934398e9f499f47w9789o9f...

$ git tag -r v0.2
v0.2  jhkd934398e9f499f47w9789o9f...


What do you think?

Thanks,
Eugene

Re: feature "git tag -r" to show tags and commits they are pointing to

[Junio C Hamano]

Eugene Sajine <euguess@gmail.com> writes:

> Hi,
>
> Currently there is no way you can get the commits your tags are
> pointing to by using git tag.
> The only way i found is to use rev-parse (which is by the way not
> supported by the bash_completion)
>
> It seems reasonable to have upper level command like:
>
> $ git tag -r
>
> to output
>
> v0.1  8794hke84f9e8h9ef9eh949793...
> v0.2  jhkd934398e9f499f47w9789o97...
>
> $ git tag -n -r
>
> v0.1 "super message"     8794hke84f9e8h9ef9eh949793...
> v0.2  "another message" jhkd934398e9f499f47w9789o9f...
>
> $ git tag -r v0.2
> v0.2  jhkd934398e9f499f47w9789o9f...
>
>
> What do you think?

Not intereseted at all, as this does not look anything more than "because
I could", not "because this is useful and sorely lacking".

The "super message" and such are actually useful to humans, but "v0.1" is
much more useful than 8794hke to humans, and these tag names are just as
usable as the hexadecimal commit object names to the tools.  You can say
"git show v0.1^0" and "git show 8794hke" and get the same thing.

Heck, "8794hke" is not even hexadecimal, and the fact that you did not
even notice it is a _S*RE_ sign that they are not useful to humans.

If you _are_ a human, that is ;-)

In other words, please do not justify such a proposal with "I want to have
'git tag' command to show the commit object name".  Rather, justify _why_
(1) you _need_ to show the commit object name to begin with, and (2) the
output _has_ to come from 'git tag' and not 'git rev-parse'.

Re: feature "git tag -r" to show tags and commits they are pointing to

[Eugene Sajine]

Please, disregard...

I was looking for this info in order to create second tag for the same
commit. For example if the first tag created by somebody or
automatically (CI, release system), so i could add a verbose tag.

But i just realized that i don't need commit id for that - just tag
the tag, stupid...

Thanks,
Eugene


On 10/22/09, Junio C Hamano <gitster@pobox.com> wrote:
> Eugene Sajine <euguess@gmail.com> writes:
>
>> Hi,
>>
>> Currently there is no way you can get the commits your tags are
>> pointing to by using git tag.
>> The only way i found is to use rev-parse (which is by the way not
>> supported by the bash_completion)
>>
>> It seems reasonable to have upper level command like:
>>
>> $ git tag -r
>>
>> to output
>>
>> v0.1  8794hke84f9e8h9ef9eh949793...
>> v0.2  jhkd934398e9f499f47w9789o97...
>>
>> $ git tag -n -r
>>
>> v0.1 "super message"     8794hke84f9e8h9ef9eh949793...
>> v0.2  "another message" jhkd934398e9f499f47w9789o9f...
>>
>> $ git tag -r v0.2
>> v0.2  jhkd934398e9f499f47w9789o9f...
>>
>>
>> What do you think?
>
> Not intereseted at all, as this does not look anything more than "because
> I could", not "because this is useful and sorely lacking".
>
> The "super message" and such are actually useful to humans, but "v0.1" is
> much more useful than 8794hke to humans, and these tag names are just as
> usable as the hexadecimal commit object names to the tools.  You can say
> "git show v0.1^0" and "git show 8794hke" and get the same thing.
>
> Heck, "8794hke" is not even hexadecimal, and the fact that you did not
> even notice it is a _S*RE_ sign that they are not useful to humans.
>
> If you _are_ a human, that is ;-)
>
> In other words, please do not justify such a proposal with "I want to have
> 'git tag' command to show the commit object name".  Rather, justify _why_
> (1) you _need_ to show the commit object name to begin with, and (2) the
> output _has_ to come from 'git tag' and not 'git rev-parse'.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: feature "git tag -r" to show tags and commits they are pointing to

[Junio C Hamano]

Eugene Sajine <euguess@gmail.com> writes:

> I was looking for this info in order to create second tag for the same
> commit. For example if the first tag created by somebody or
> automatically (CI, release system), so i could add a verbose tag.
>
> But i just realized that i don't need commit id for that - just tag
> the tag, stupid...

You do not have to live with a tag that points at another tag that points
at a commit.

You can still tag the commit directly with your new tag, and you do not
need to have the exact commit object name to do so.  You just tell the
tool to follow the tag chain to get to the pointed-to object, like this:

    $ git tag -a -m "my message" newtag oldtag^0

This assumes [*1*] that the old tag points at (strictly speaking, "might
point at") a commit object, and uses "^0" (zeroth parent of) operator to
make sure that the object the newtag points at (the last argument to the
"git tag" command, i.e. "oldtag^0" in this example) is a commit object,
not an annotated tag "oldtag" itself.

That is what I meant by "just as usable as hexadecimal to the tools".

>> ... "v0.1" is
>> much more useful than 8794hke to humans, and these tag names are just as
>> usable as the hexadecimal commit object names to the tools.  You can say
>> "git show v0.1^0" and "git show 8794hke" and get the same thing.

[Footnote]

*1* A tag can point at any object, not necessarily a commit.  If oldtag
points at a tree object (or a blob object), oldtag^0 will fail, because
the operator "^0" is "zeroth parent of", and is applicable only to a
commit.  In general, you can write

    $ git tag -a -m "my message" newtag oldtag^{}

The "^{}" operator is a special case of "^{type}" operator; the former
means "dereference the tag repeatedly until it becomes something that is
not a tag", and the latter means "dereference the tag repeatedly until it
becomes something of that type".  I.e. "oldtag^0" is "oldtag^{commit}".

Re: feature "git tag -r" to show tags and commits they are pointing to

[Eugene Sajine]

> You do not have to live with a tag that points at another tag that points
> at a commit.
>
> You can still tag the commit directly with your new tag, and you do not
> need to have the exact commit object name to do so.  You just tell the
> tool to follow the tag chain to get to the pointed-to object, like this:
>
>    $ git tag -a -m "my message" newtag oldtag^0
>
> This assumes [*1*] that the old tag points at (strictly speaking, "might
> point at") a commit object, and uses "^0" (zeroth parent of) operator to
> make sure that the object the newtag points at (the last argument to the
> "git tag" command, i.e. "oldtag^0" in this example) is a commit object,
> not an annotated tag "oldtag" itself.
>
> That is what I meant by "just as usable as hexadecimal to the tools".
>
>>> ... "v0.1" is
>>> much more useful than 8794hke to humans, and these tag names are just as
>>> usable as the hexadecimal commit object names to the tools.  You can say
>>> "git show v0.1^0" and "git show 8794hke" and get the same thing.
>
> [Footnote]
>
> *1* A tag can point at any object, not necessarily a commit.  If oldtag
> points at a tree object (or a blob object), oldtag^0 will fail, because
> the operator "^0" is "zeroth parent of", and is applicable only to a
> commit.  In general, you can write
>
>    $ git tag -a -m "my message" newtag oldtag^{}
>
> The "^{}" operator is a special case of "^{type}" operator; the former
> means "dereference the tag repeatedly until it becomes something that is
> not a tag", and the latter means "dereference the tag repeatedly until it
> becomes something of that type".  I.e. "oldtag^0" is "oldtag^{commit}".
>

Junio,

Thank you very much for such detailed explanation! I do appreciate it.


Eugene