Jeff King <p...@peff.net> writes:
> On Wed, Nov 19, 2014 at 10:45:48AM -0800, Junio C Hamano wrote:
>
>> ... tags are meant to be used for globally shared
>> anchoring points and the whole machinery (e.g. "fetch" that
>> auto-follows tags, "clone" that gives refs/tags*:refs/tags/*
>> refspec) is geared towards supporting that use pattern, which will
>> be broken by moving tags to per-remote namespace.
>>
>> I can see "git tag --local foo" that creates refs/local-tags/foo
>> and also adding a mechanism to propagate local-tags/ hierarchy just
>> like heads/ hierarchy is propagated per-remote as a solution to that
>> problem that does not break the "release tags" use case, though.
>
> I am not sure I agree here that the discussions in [2] were not handling
> this case. Here you are arguing for the tag-writer to distinguish
> between two separate namespaces: global and local.
>
> But I think the proposals in [2] were about pushing that logic into the
> lookup phase. That is, pulling in all of the remote's tags as
> "refs/remotes/origin/tags/*", and then at lookup time checking multiple
> locations for tags (and preferring your local "refs/tags" to what is
> pulled from a remote).
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.
Aside from the mantra that it is a good thing to reduce the workload
for people closer to the center of the project (hence likely to be
bottleneck to slow down others) and a separate local-tags hierarchy
is a way to achieve that, a separate local-tags hierarchy also helps
people who do not make releases by letting them easily differenciate
the global tags they get from the project and the tags they and
other project participants create as private markers (their own will
be found in refs/local-tags, others' in refs/remotes/$pal/local-tags).
> ...
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
