Re: Strange annotated tag issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 25, 2019 at 08:50:14AM -0500, Robert Dailey wrote:

> On Thu, Mar 21, 2019 at 2:29 PM Jeff King <peff@xxxxxxxx> wrote:
> > Tags can point to any object, including another tag. It looks like
> > somebody made an annotated tag of an annotated tag (probably by
> > mistake, given that they have the same tag-name).
> [..]
> Thanks for explaining. This is very helpful. Am I naive to think that
> this should be an error? I haven't seen a valid _pragmatic_ use for
> tags pointing to tags. In 100% of cases (including this one), it is
> done out of error. As per your example, users try to "correct" an
> annotated tag pointing at a wrong tag or commit. What they expect is
> the tag to point to the other tag's commit, but that's not what they
> get.

I don't think I've ever seen a tag-to-a-tag in the wild, but I wouldn't
be surprised if somebody has found a use for it. For example, because
tags can be signed, I can make a signature of your signature, showing a
cryptographic chain of custody.

And at any rate, it has been allowed in the data model for almost 15
years, so I think disallowing it now would be a bad idea. It might be
acceptable to introduce a safety valve into the porcelain, though.

> From a high-level, pragmatic perspective, doesn't it make more sense
> to change the git behavior so that annotated tags may only point to
> commit objects? And in the `git tag -f -m outer mytag mytag` case in
> your example, this would automatically perform `mytag^{}` to ensure
> that the behavior the user expects is the behavior they get?

I think "just commits" is too restrictive. linux.git contains a tag of a
tree, for example (we also have tags pointing to blobs in git.git, but
they are not annotated).

However, I could see an argument for the git-tag porcelain to notice a
tag-of-tag and complain. Probably peeling the tag automatically is a bad
idea, just because it behaved differently for so long. But something
like might be OK:

  $ git tag -a mytag
  error: refusing to make a recursive tag
  hint: The object 'mytag' referred to by your new tag is already a tag.
  hint:
  hint: If you meant to create a tag of a tag, use:
  hint:
  hint:  git tag -a -f mytag
  hint:
  hint: If you meant to tag the object that it points to, use:
  hint:
  hint:  git tag -a mytag^{}

It would be a minor annoyance to somebody who frequently makes
tags-of-tags, but it leaves them with an escape hatch.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux