git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Nicolas Pitre <nico@fluxnic.net>
To: Jeff King <peff@peff.net>
Cc: "Michael Haggerty" <mhagger@alum.mit.edu>,
	"Junio C Hamano" <gitster@pobox.com>,
	git@vger.kernel.org, "Carlos Martín Nieto" <cmn@elego.de>,
	"Michael Schubert" <mschub@elegosoft.com>,
	"Johan Herland" <johan@herland.net>
Subject: Re: Local tag killer
Date: Wed, 25 Sep 2013 18:54:10 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.03.1309251834210.312@syhkavp.arg> (raw)
In-Reply-To: <20130924075119.GD7257@sigill.intra.peff.net>

On Tue, 24 Sep 2013, Jeff King wrote:

> On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote:
> 
> > I think it would be preferable if "--prune" would *not* affect tags, and
> > if there were an extra option like "--prune-tags" that would have to be
> > used explicitly to cause tags to be pruned.  Would somebody object to
> > such a change?
> 
> I think most of this problem is the way that we fetch tags straight into
> the refs/tags hierarchy. You would not do:
> 
>   [remote "origin"]
>   fetch = +refs/heads/*:refs/heads/*
>   prune = true
> 
> unless you wanted to be a pure-mirror, because you would hose your local
> changes any time you fetched. But that is _exactly_ what we do with a
> refs/tags/*:refs/tags/* fetch.
> 
> If we instead moved to a default fetch refspec more like:
> 
>   [remote "origin"]
>   fetch = +refs/*:refs/remotes/origin/refs/*
> 
> Then everything would Just Work. If you prune what the other side has
> locally, that's fine. All you're doing is pruning your view of what he
> has, not anything you've done locally.
> 
> The tricky part is tweaking the lookup rules so that "origin/master"
> still works, and that looking for "v1.0" checks both refs/tags and
> refs/remotes/*/refs/tags. And of course managing backwards
> compatibility. :)

Cheers !!!

I remember participating to a discussion about this like 2.5 years ago:

http://news.gmane.org/group/gmane.comp.version-control.git/thread=165799

The flat tag namespace remains my major annoyance with git IMHO.


Nicolas

  parent reply	other threads:[~2013-09-25 22:54 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-13  2:54 Local tag killer Michael Haggerty
2013-09-13  4:03 ` Junio C Hamano
2013-09-20 22:51   ` Junio C Hamano
2013-09-21  6:42     ` Michael Haggerty
2013-09-21 12:28       ` John Szakmeister
2013-09-24  7:51       ` Jeff King
2013-09-24 13:22         ` Marc Branchaud
2013-09-25  8:22           ` Jeff King
2013-09-25 22:54         ` Nicolas Pitre [this message]
2013-09-28 12:20           ` Michael Haggerty
2013-09-28 21:42             ` Johan Herland
2013-09-29  4:29               ` Michael Haggerty
2013-09-29  9:30                 ` Johan Herland
2013-09-30 15:24                 ` Marc Branchaud
2013-09-30 15:52                   ` Nicolas Pitre
2013-09-30 19:16                     ` Marc Branchaud
2013-09-30 20:08                       ` Nicolas Pitre
2013-09-30 21:14                         ` Marc Branchaud
2013-09-30 22:44                           ` Nicolas Pitre
2013-09-30 23:18                             ` Jeff King
2013-10-01  3:04                             ` Marc Branchaud
2013-10-01  3:28                               ` Nicolas Pitre
2013-10-01 12:45                                 ` Marc Branchaud
2013-10-23 15:50 ` [PATCH 00/15] Change semantics of "fetch --tags" Michael Haggerty
2013-10-23 15:50   ` [PATCH 01/15] t5510: use the correct tag name in test Michael Haggerty
2013-10-23 15:50   ` [PATCH 02/15] t5510: prepare test refs more straightforwardly Michael Haggerty
2013-10-23 18:36     ` Junio C Hamano
2013-10-24  6:49       ` Michael Haggerty
2013-10-24 19:50         ` Junio C Hamano
2013-10-23 15:50   ` [PATCH 03/15] t5510: check that "git fetch --prune --tags" does not prune branches Michael Haggerty
2013-10-23 15:50   ` [PATCH 04/15] api-remote.txt: correct section "struct refspect" Michael Haggerty
2013-10-23 18:43     ` Junio C Hamano
2013-10-24  7:06       ` Michael Haggerty
2013-10-23 15:50   ` [PATCH 05/15] get_ref_map(): rename local variables Michael Haggerty
2013-10-23 18:45     ` Junio C Hamano
2013-10-24  7:24       ` Michael Haggerty
2013-10-23 15:50   ` [PATCH 06/15] ref_remove_duplicates(): avoid redundant bisection Michael Haggerty
2013-10-23 15:50   ` [PATCH 07/15] ref_remove_duplicates(): simplify function Michael Haggerty
2013-10-23 15:50   ` [PATCH 08/15] ref_remove_duplicates(): improve documentation comment Michael Haggerty
2013-10-23 18:47     ` Junio C Hamano
2013-10-23 15:50   ` [PATCH 09/15] builtin/fetch.c: reorder function definitions Michael Haggerty
2013-10-23 15:50   ` [PATCH 10/15] fetch --tags: fetch tags *in addition to* other stuff Michael Haggerty
2013-10-24 20:51     ` Junio C Hamano
2013-10-25 15:08       ` Michael Haggerty
2013-10-28 19:10         ` Junio C Hamano
2013-10-30  4:26           ` Michael Haggerty
2013-10-26  5:10       ` Michael Haggerty
2013-10-23 15:50   ` [PATCH 11/15] fetch --prune: prune only based on explicit refspecs Michael Haggerty
2013-10-24 21:11     ` Junio C Hamano
2013-10-26  6:49       ` Michael Haggerty
2013-10-28 15:08         ` Junio C Hamano
2013-10-23 15:50   ` [PATCH 12/15] query_refspecs(): move some constants out of the loop Michael Haggerty
2013-10-23 15:50   ` [PATCH 13/15] builtin/remote.c: reorder function definitions Michael Haggerty
2013-10-23 15:50   ` [PATCH 14/15] builtin/remote.c:update(): use struct argv_array Michael Haggerty
2013-10-23 15:50   ` [PATCH 15/15] fetch, remote: properly convey --no-prune options to subprocesses Michael Haggerty
2013-10-24 21:17     ` Junio C Hamano
2013-10-23 16:59   ` [PATCH 00/15] Change semantics of "fetch --tags" Junio C Hamano

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=alpine.LFD.2.03.1309251834210.312@syhkavp.arg \
    --to=nico@fluxnic.net \
    --cc=cmn@elego.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johan@herland.net \
    --cc=mhagger@alum.mit.edu \
    --cc=mschub@elegosoft.com \
    --cc=peff@peff.net \
    /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).