All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Denton Liu <liu.denton@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Robert Dailey" <rcdailey.lists@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Elijah Newren" <newren@gmail.com>
Subject: Re: [PATCH v2.5 2/2] tag: prevent nested tags
Date: Wed, 3 Apr 2019 22:02:26 -0400	[thread overview]
Message-ID: <20190404020226.GG4409@sigill.intra.peff.net> (raw)
In-Reply-To: <20190403213318.GA14137@dev-l>

On Wed, Apr 03, 2019 at 02:33:18PM -0700, Denton Liu wrote:

> > I am not sure if this is so bad, actually.  Why do we need to treat
> > it as a mistake?  When a command that wants a commit is fed a tag
> > (either a tag that directly refers to a commit, or a tag that tags
> > another tag that refers to a commit), the command knows how to peel
> > so it's not like the user is forced to say "git log T^{commit}".
> 
> This patch came about because Robert Dailey expressed confusion after
> accidentally creating a tag-to-a-tag a while back by mistake when he
> actually meant to amend a tag.
> 
> In the discussion upthread, Peff noted that he has never seen a
> tag-to-a-tag in the wild before. I think the conclusion was that for
> the majority of users, doing this is an error. That is what this patch
> is guarding against.

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.

The only thing that caused the discussion in the first place is that
when "git show" displays each layer, there was a little head-scratching.

So if we were starting from scratch and designing the behavior, I think
putting a safety valve around this mistake would probably be a
no-brainer.

But given that we're changing long-standing behavior (that somebody
_could_ be using intentionally), is it worth it to fix what is a mostly
harmless outcome?

I'm on the fence personally. I think I do still lean slightly towards
"yes, detect this in the porcelain", but I can see an argument both
ways.

-Peff

  reply	other threads:[~2019-04-04  2:02 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-21 16:59 Strange annotated tag issue Robert Dailey
2019-03-21 19:04 ` Bryan Turner
2019-03-21 19:39   ` Jeff King
2019-03-21 19:29 ` Jeff King
2019-03-25 13:50   ` Robert Dailey
2019-03-25 14:49     ` Jeff King
2019-03-25 15:31       ` Robert Dailey
2019-03-25 18:43       ` Bryan Turner
2019-03-25 23:36         ` Jeff King
2019-03-25 19:19       ` Ævar Arnfjörð Bjarmason
2019-03-25 23:37         ` Jeff King
2019-03-26  7:53           ` [PATCH 0/3] tag: prevent recursive tags Denton Liu
2019-03-26  7:53             ` [PATCH 1/3] " Denton Liu
2019-03-26  8:51               ` Denton Liu
2019-03-26 10:10               ` Ævar Arnfjörð Bjarmason
2019-03-27  4:57               ` Elijah Newren
2019-03-27 10:27                 ` Ævar Arnfjörð Bjarmason
2019-03-28 19:02                   ` Robert Dailey
2019-03-26  7:53             ` [PATCH 2/3] t7004: ensure recursive tag behavior is working Denton Liu
2019-03-26 10:11               ` Ævar Arnfjörð Bjarmason
2019-03-26  7:53             ` [PATCH 3/3] git-tag.txt: document --allow-recursive-tag option Denton Liu
2019-03-26 10:16               ` Ævar Arnfjörð Bjarmason
2019-03-26 16:18             ` [PATCH 0/3] tag: prevent recursive tags Jeff King
2019-04-02  5:38             ` [PATCH v2 0/2] tag: prevent nested tags Denton Liu
2019-04-02  5:38               ` [PATCH v2 1/2] tag: fix formatting Denton Liu
2019-04-02  5:38               ` [PATCH v2 2/2] tag: prevent nested tags Denton Liu
2019-04-02 23:03                 ` [PATCH v2.5 " Denton Liu
2019-04-03  7:32                   ` Junio C Hamano
2019-04-03  8:49                     ` Junio C Hamano
2019-04-03 18:26                       ` Robert Dailey
2019-04-04  9:32                         ` Junio C Hamano
2019-04-04 13:47                           ` Robert Dailey
2019-04-04 21:50                             ` Junio C Hamano
2019-04-05  2:51                               ` Robert Dailey
2019-04-03 18:16                     ` Johannes Sixt
2019-04-03 21:33                     ` Denton Liu
2019-04-04  2:02                       ` Jeff King [this message]
2019-04-04  9:31                         ` Junio C Hamano
2019-04-04 12:27                           ` Jeff King
2019-04-04 21:54                             ` Junio C Hamano
2019-04-04 22:12                               ` Jeff King
2019-04-11 18:40                             ` Eckhard Maaß
2019-04-12  3:21                               ` Junio C Hamano
2019-04-05  0:36                           ` Elijah Newren
2019-04-05  5:29                             ` Junio C Hamano
2019-04-04 18:25               ` [PATCH v3 0/2] tag: advise on recursive tagging Denton Liu
2019-04-04 18:25               ` [PATCH v3 1/2] tag: fix formatting Denton Liu
2019-04-04 18:25               ` [PATCH v3 2/2] tag: advise on nested tags Denton Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190404020226.GG4409@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=liu.denton@gmail.com \
    --cc=newren@gmail.com \
    --cc=rcdailey.lists@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.