Re: [PATCH v2.5 2/2] tag: prevent nested tags

[Elijah Newren <newren@gmail.com>]

On Thu, Apr 4, 2019 at 2:31 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Jeff King <peff@peff.net> writes:
>
> > I do still think it is likely to be a mistake. I think Junio's point,
> > though is: who cares if the mistake was made? For the most part you can
> > continue to use the tag as if the mistake had never been made, because
> > Git peels through multiple layers as necessary.
>
> Nicely said.
>
> If we forget to peel, that is a bigger problem, but I do not think
> it makes any sense to single out tag-of-tag as "curious" and forbid
> it, when we silently allow tag-of-blob or tag-of-tree happily.
>
> An opt-in (i.e. default to false) tag.allowTaggingOnlyCommits I do
> not have any problem with, and I could be persuaded into taking an
> opt-out (i.e. default to true) tag.forbidTaggingAnythingButCommits
> configuration, perhaps, though.

I'm slightly in favor of the tag.forbidTaggingAnythingButCommits
route.  Two reasons:

  * Even core git commands can't handle these properly after more than
a decade, making me suspect that tools in the greater git ecosystem
are going to fail to handle them too.  In more detail...  Some
examples: fast-export with --tag-of-filtered-object=rewrite fails on
tags of tags and tags of blobs.  Without that flag, I think
fast-export munges tags of tags, but maybe that was only under some
other special case; I don't remember right now.  Also, filter-branch
munges tags of tags (though maybe that's documented; it may have
decided that tags of tags are an error in need of fixing with no flag
for users to opt out).  Considering core tools that have been part of
git for over a decade mishandle tags of anything other than commits
(or maybe even treat them as erroneous), I don't see why we'd expect
tools outside of git to handle them correctly.  Thus, I think it'd be
nice if people had to specify some kind of way to state they are sure
they want to tag something other than a commit.

  * The only two repositories I know of and have access to which has
such tags are linux.git (a tag of a tree) and git.git (a tag of a blob
and four or so tags of tags).  Further, these tags are all pretty old
too.  So, I think disallowing the creation of tags of non-commit
objects would be unlikely to negatively impact existing users.


Though, on the flipside, given how rare these seem to be in practice,
it might not be worth the effort.  Certainly not at the top of my
priority list.

Elijah