All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denton Liu <liu.denton@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Git Mailing List" <git@vger.kernel.org>,
	"Robert Dailey" <rcdailey.lists@gmail.com>,
	"Jeff King" <peff@peff.net>,
	"Æ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 14:33:18 -0700	[thread overview]
Message-ID: <20190403213318.GA14137@dev-l> (raw)
In-Reply-To: <xmqqzhp7sfw4.fsf@gitster-ct.c.googlers.com>

On Wed, Apr 03, 2019 at 04:32:27PM +0900, Junio C Hamano wrote:
> Denton Liu <liu.denton@gmail.com> writes:
> 
> > This is the first use of the '%n$<fmt>' style of printf format in the
> > *.[ch] files in our codebase, but it's supported by POSIX[1] and there
> > are existing uses for it in po/*.po files, so hopefully it won't cause
> 
> The latter is a stronger indication that this should be OK than the
> former ;-)  Thanks for digging and noting.

Thank Ævar, I shamelessly stole this message from one of his patches
that didn't get included in[1].

> 
> > diff --git a/Documentation/config/advice.txt b/Documentation/config/advice.txt
> > index 88620429ea..ec4f6ae658 100644
> > --- a/Documentation/config/advice.txt
> > +++ b/Documentation/config/advice.txt
> > @@ -90,4 +90,6 @@ advice.*::
> >  	waitingForEditor::
> >  		Print a message to the terminal whenever Git is waiting for
> >  		editor input from the user.
> > +	nestedTag::
> > +		Advice shown if a user attempts to recursively tag a tag object.
> >  --
> 
> In addition to 'advice', we may have to add a configuration to help
> projects that wants to tag tag objects regularly so that they do not
> have to keep typing "--allow-nested-tag".  But that can wait until a
> participant of such a project comes forward and makes a case for
> their workflow.
> 
> > +chain of custody by signing someone else's signed tag. However, in
> > +practice, this is typically a mistake so we prevent it from happening by
> > +default unless specifically requested.
> 
> 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.

> 
> And if something that *MUST* take a commit refuses to (or more
> likely, forges to) peel a tag down to a commit and yields an error,
> I think that is what needs fixing, not the command that creates a
> tag.
> 
> So, I am fairly negative on this change---unless it is made much
> more clear in the doc and/or in the proposed log message what
> practical downside there are to the end users if we do not stop this
> "mistake", that is.

I can update the log message to include more detail.

> 
> > +Automatically erroring on nested tags was introduced in Git version
> > +2.22.0.
> 
> And please do not write something like this.  A feature gets in a
> release when it is ready, and we may not ship this in 2.22.

Ævar suggested that we include this because git tag gets used by a lot
of scripts so in case one ever starts failing, a maintainer can more
easily track down the reason why.

> 
> "git tag --help" the user is running may or may not have the
> paragraph about "nested tag", depending on the existence of the
> feature in the version of Git the user is running, so there is no
> need to say something like that.
> 
> And no, I do not buy arguments like "random web servers serve
> different versions of documentation without identifying which
> version of Git they describe".
> 

Thanks for the comments,

Denton

[1]: https://public-inbox.org/git/20181026192734.9609-8-avarab@gmail.com/

  parent reply	other threads:[~2019-04-03 21:33 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 [this message]
2019-04-04  2:02                       ` Jeff King
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=20190403213318.GA14137@dev-l \
    --to=liu.denton@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --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.