On Wed, Mar 27, 2019 at 5:27 AM Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> wrote:
>
>
> On Wed, Mar 27 2019, Elijah Newren wrote:
>
> > On Tue, Mar 26, 2019 at 12:56 AM Denton Liu <liu.denton@xxxxxxxxx> wrote:
> >>
> >> Robert Dailey reported confusion on the mailing list about a recursive
> >> tag which was most likely created by mistake. Jeff King noted that this
> >> isn't a very common case so, most likely, creating a tag-to-a-tag is a
> >> user-error.
> >>
> >> Prevent mistakes by erroring and providing advice on recursive tags,
> >> unless "--allow-recursive-tag" is specified. Fix tests that fail as a
> >> result of this change.
> >
> > Any chance we could use the term "nested tag" instead of "recursive tag"?
>
> +1. "Recursive" sounded wrong to me, but I couldn't think of the
> now-obvious alternative.
>
> Some grepping around shows we use "nested submodules" fairly
> consistently, and in gitrevisions(7) we say the peel syntax will
> recursively peel tags (but don't call them nested).
>
> So makes sense to refer to the object type as nested, and when we're
> referring to the operation that'll iterate over that nested structure
> say it'll be done "recursively".
Wow thanks for fixing this, you guys are awesome. I wasn't expecting
anyone to fix this since it seemed kinda niche. You're right that I
created this nested tag unintentionally. And due to `git-lfs migrate`
not handling nested annotated tags, it took days of debugging to
eventually figure out that nothing was working because of 1 farkled
tag.
Just to make sure I understand the change, is a tag pointing to
another tag object now going to be forbidden by default? And to allow
it, you must do `git tag --allow-nested-tag`?
So for example, going forward, if we have this:
$ git tag -m 'Tag 1' 1.0
$ git tag -m 'Tag 2' 2.0
This will fail:
$ git tag -f 2.0 1.0
Unless I do either:
$ git tag --allow-nested-tag -f 2.0 1.0
Or (this is the intended behavior in my case):
$ git tag -f 2.0 1.0^{}
