git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Drew Northup <n1xim.email@gmail.com>
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
	Angelo Borsotti <angelo.borsotti@gmail.com>,
	Philip Oakley <philipoakley@iee.org>,
	Chris Rorvick <chris@rorvick.com>, Johannes Sixt <j6t@kdbg.org>,
	git <git@vger.kernel.org>
Subject: Re: git push tags
Date: Mon, 29 Oct 2012 07:35:00 -0400	[thread overview]
Message-ID: <20121029113500.GA15597@sigill.intra.peff.net> (raw)
In-Reply-To: <CAM9Z-nkf84cV2bYp=NL8an5DjvwP+jL7icb+jwizjHeaq40VhA@mail.gmail.com>

On Mon, Oct 29, 2012 at 07:21:52AM -0400, Drew Northup wrote:

> > I would have expected git to at least complain about updating an
> > annotated tag with another annotated tag. But it actually uses the same
> > fast-forward rule, just on the pointed-to commits. So a fast-forward
> > annotated re-tag will throw away the old tag object completely. Which
> > seems a bit crazy to me.
> >
> > It seems like a no-brainer to me that annotated tags should not replace
> > each other without a force, no matter where in the refs hierarchy they
> > go.
> >
> > For lightweight tags, I think it's more gray. They are just pointers
> > into history. Some projects may use them to tag immutable official
> > versions, but I also see them used as shared bookmarks. Requiring "-f"
> > may make the latter use more annoying. On the other hand, bookmark tags
> > tend not to be pushed, or if they are, it is part of a mirror-like
> > backup which should be forcing all updates anyway.
> 
> Would that be an endorsement of continuing to build a patch set
> including the snippet that Kacper posted earlier (1) in response to my
> comment about not being sure how complicated all of this would be or
> not?

That patch just blocks non-forced updates to refs/tags/. I think a saner
start would be to disallow updating non-commit objects without a force.
We already do so for blobs and trees because they are not (and cannot
be) fast forwards. The fact that annotated tags are checked for
fast-forward seems to me to be a case of "it happens to work that way"
and not anything planned. Since such a push drops the reference to the
old version of the tag, it should probably require a force.

Then on top of that we can talk about what lightweight tags should do.
I'm not sure. Following the regular fast-forward rules makes some sense
to me, because you are never losing objects. But there may be
complications with updating tags in general because of fetch's rules,
and we would be better off preventing people from accidentally doing so.
I think a careful review of fetch's tag rules would be in order before
making any decision there.

-Peff

  parent reply	other threads:[~2012-10-29 11:35 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-25  6:58 git push tags Angelo Borsotti
2012-10-25 17:19 ` Drew Northup
2012-10-25 19:05   ` Angelo Borsotti
2012-10-25 21:16     ` Drew Northup
2012-10-26  6:42       ` Angelo Borsotti
2012-10-26 13:37         ` Drew Northup
2012-10-26 13:59           ` Chris Rorvick
2012-10-26 14:13             ` Drew Northup
2012-10-26 14:23               ` Chris Rorvick
2012-10-26 15:23           ` Angelo Borsotti
2012-10-26 17:42       ` Kacper Kornet
2012-10-26 18:07         ` Drew Northup
2012-10-26 18:20           ` Kacper Kornet
2012-10-26 18:35             ` Angelo Borsotti
2012-10-26 19:00               ` Kacper Kornet
2012-10-26 19:08                 ` Drew Northup
2012-10-28 18:15 ` Johannes Sixt
2012-10-28 19:59   ` Chris Rorvick
2012-10-28 21:49     ` Philip Oakley
2012-10-28 23:58       ` Drew Northup
2012-10-29  2:15       ` Chris Rorvick
2012-10-29  7:13       ` Angelo Borsotti
2012-10-29  8:12         ` Angelo Borsotti
2012-10-29  9:58           ` Michael Haggerty
2012-10-29 10:38             ` Jeff King
2012-10-29 11:21               ` Drew Northup
2012-10-29 11:31                 ` Angelo Borsotti
2012-10-29 11:35                 ` Jeff King [this message]
2012-10-29 12:25                   ` Drew Northup
2012-10-29 13:24                   ` Angelo Borsotti
2012-10-29 17:23                   ` Kacper Kornet
2012-10-29 21:35                     ` Jeff King
2012-10-30 17:09                       ` Chris Rorvick
     [not found]                         ` <CAB9Jk9CC9wjeyggejkVjKgY2HGAFw70hJo-S0S-W-p4gnd2zug@mail.gmail.com>
2012-10-30 19:11                           ` Chris Rorvick
2012-10-29 10:10           ` Kacper Kornet

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20121029113500.GA15597@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=angelo.borsotti@gmail.com \
    --cc=chris@rorvick.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=mhagger@alum.mit.edu \
    --cc=n1xim.email@gmail.com \
    --cc=philipoakley@iee.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).