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

[Robert Dailey <rcdailey.lists@gmail.com>]

On Thu, Apr 4, 2019 at 4:50 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Robert Dailey <rcdailey.lists@gmail.com> writes:
>
> > It might be fine within the realm of git itself, because git knows how
> > to deal with them by peeling, as you say, but there are 3 reasons I
> > dislike that this is allowed:
>
> That sounds as if you have tools that forgets to peel when it should
> in mind.  Isn't that what you should be looking into fixing?  After
> all, tools that aim to work with Git should strive to come close to
> "within the realm of git itsef" in the modern world.
>
> > 1. The intent by the user was to create a tag pointing to the commit
> > that another tag points to.
>
> You make it sound as if you are convinced that is the truth.  I am
> not.  If I want to tag the commit pointed at by tag v1.0, I'd say I
> want to tag "v1.0^0", because otherwise there won't be a way to say
>
>     $ git tag -s -m "i am aware of this tag" initial v1.0
>
> i.e. making a tag that points at a tag.  So I take the lack of ^0
> (or ^{commit}) peeling an explicit sign that shows the intent by the
> user (well, those who know the tool, anyway) is clearly to create a
> tag pointing to that tag.  In other words, peeling at the tagging
> time is wrong, and rejecting tag creation is also wrong.
>
> > 2. When users on my team do a `git show tag`, they see 2 descriptions
> > and 2 tags. This creates a LOT of confusion.
>
> So what?  Not everybody will forever stay to be a newbie ;-)
>
> As I said, an opt-in tag.allowCommitOnly is fine.  That would train
> their fingers to peel with ^{commit} when they want to tag a commit.
> An opt-in tag.autoPeelTags might also be fine, even though that
> would not help training their fingers (so they will have to be
> prepared for the same "confusion" on a fresh machine)
>
> When the command line clearly tells us that the user wants to tag a
> tag, we should not get overly "smart" and refuse to create a tag of
> a tag, unless the user tells us otherwise with some means.
>
> > 3. Even if Git internally handles peeling tags, external 3rd party
> > tooling may not. As I mentioned in another thread, `git lfs migrate`
> > was not programmed to peel tags. I reported the issue here:
>
> That is good, and it is the right way.  After all, external 3rd
> party tooling may tag a tag even after we castrate "git tag" to be
> incapable of doing so, so a bug like the one you are helping to fix
> in lfs needs to be fixed anyway.  In other words, thats the only
> sensible way forward when you care about the entire Git ecosystem,
> not just the main/reference implementation we work on here.
>

Look, I'm not saying you're wrong. You're probably absolutely right
about all the technical details. You know a lot more about this than I
do, that's for sure. But based on my observations and experience,
everything you're saying isn't set in reality. I have guys on my team
at work that haven't learned anything significant about Git in the
past 3 years; they don't care to learn it. They use a GUI tool for
everything and it's a means to an end for them. Most folks just want
to check out branches, merge, and push commits. They don't understand
what objects or blobs are, or what a tree vs tag vs commit is. Hell, I
have trouble explaining rebase to most people, and that's arguably
much more straightforward. But all of this is OK. We're hired to be
programmers, not experts at Git.

I think what needs to be right is what most people expect, and from my
experience that's not in alignment with your opinion on how this
should work. And I want to apologize if it seems like I'm arguing with
you. My intent is just to clarify my point of thinking. I feel like
you're still very wrapped up in the bowels of Git and the deep
technical details. I just want to make sure I'm being clear about my
perspective, since I'm approaching this from a somewhat non-technical
angle.

Again, regardless of what gets decided, I very much appreciate
everyone looking into this. I feel like whatever you folks come up
with will ultimately be the best decision, even if it may not be 100%
what I'm expecting.