From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Brian Norris <computersforpeace@gmail.com>, git@vger.kernel.org
Subject: Re: git-fetch: default globally to --no-tags
Date: Wed, 19 Nov 2014 15:32:09 -0500 [thread overview]
Message-ID: <20141119203208.GA11053@peff.net> (raw)
In-Reply-To: <xmqqa93nrldf.fsf@gitster.dls.corp.google.com>
On Wed, Nov 19, 2014 at 12:22:36PM -0800, Junio C Hamano wrote:
> With a separate local-tags hierarchy, the look-up part still has to
> be enhanced. After doing "git tag v2.0" and "git tag -l snapshot00",
> you would want to be able to say "git log snapshot00..v2.0" and have
> these found.
>
> If you don't allow a private local-tags hierarchy, then those who
> make releases are burdened to be very careful not to contaminate
> their public repository --- "git tag snapshot00" cannot be used by
> them lightly just to mark their private state, if their day
> typically is concluded with "git push --follow-tags", as that will
> push out the "tags" that are meant to be private.
It's not that I want to disallow a private local-tags hierarchy. It's
just that I consider it a completely orthogonal feature. In other words,
the problem of tags in a global namespace is not solved at all by
local-tags. It just helps people keep things out of the global namespace
that they did not want to be there in the first place[1]. It does
nothing for viewers who need to coalesce multiple global tag namespaces
(either from multiple projects, or "proposals" of global tags they have
pulled in from other non-canonical repositories).
> > But the superproject is pulling them both together; if it uses
> > refs/tags, the global namespaces will clash. Instead, it would be more
> > convenitn to have refs/remotes/project1/tags and so on.
>
> Yeah, but isn't it an orthogonal issue? refs/tags/project{1,2}/*
> would be what I would recommend to use for "global" stuff whose
> purpose is to give people a shared world view.
How do they get that split? They cannot use tag auto-following, which
puts the tags in the global refs/tags.
Certainly it can be done with git _today_ by setting up the appropriate
refspecs. I think this is more about making things useful out of the
box.
-Peff
[1] I am actually not convinced that the mixing of local and global tags
is a huge problem in practice. We do not push tags by default, so
local tags tend to stay local. OTOH, I think the world would be a
better place if "git push --follow-tags" were the default, which
would entail somehow separating global from local tags.
prev parent reply other threads:[~2014-11-19 20:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 3:05 git-fetch: default globally to --no-tags Brian Norris
2014-11-19 18:42 ` Jeff King
2014-11-19 18:45 ` Junio C Hamano
2014-11-19 18:57 ` Jeff King
2014-11-19 20:22 ` Junio C Hamano
2014-11-19 20:32 ` Jeff King [this message]
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=20141119203208.GA11053@peff.net \
--to=peff@peff.net \
--cc=computersforpeace@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.