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 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 NNTP newsgroup(s).