All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Denton Liu" <liu.denton@gmail.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: Thu, 4 Apr 2019 18:12:08 -0400	[thread overview]
Message-ID: <20190404221208.GA30798@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqef6he8sh.fsf@gitster-ct.c.googlers.com>

On Fri, Apr 05, 2019 at 06:54:06AM +0900, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > but you have to take pretty specific steps to get a tag of a blob or
> > tree, like:
> >
> >   git tag mytag HEAD:path
> >
> > or
> >
> >   git tag mytag HEAD^{tree}
> 
> And the way to ask for commit and tag are
> 
>     git tag mytag master
>     git tag mytag v1.0.0
> 
> I do not see why only the last one should either be forbidden or
> automaticallly peel.  Each of these four names an object of a
> specific type, and singling out a tag as "curious" makes the
> interface uneven.

My point is that it's easy to accidentally tag a tag. It's not easy to
accidentally tag a tree. The counter example would be something that
looks as easy as your "git tag mytag v1.0.0" but actually tags a tree.
I couldn't think of one.

I do buy the argument that arguing for safety valves from a point of
"what's the easiest mistake to make in our current interface" might not
be the best one. It yields a set of operations that aren't necessarily
sensible or orthogonal with respect to the underlying reality of what's
possible and what's reasonable. Which I think is the point you're
making.

-Peff

  reply	other threads:[~2019-04-04 22:12 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
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 [this message]
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=20190404221208.GA30798@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.