Are there issues with putting a "/" in a git tag name to create hierarchical/nested tags?

Question

We created a tag "2012/02/16" on our git repository. We then noticed that inside of Source Tree the 2012 and 01 were represented as folders which could neatly be opened and closed to reveal and hide the tags. Having a nested hierarchy of tags seems like a nice way to organize the tags instead of just having one flat list.

Is there an issue with doing this?

When I do a git ls-remote I see the following entries:

8430572c89362b875109628c33a18e782aa38488    refs/tags/2012/02/16
d247e38159c8c4998bf8b555edfd7ffe7b945255    refs/tags/2012/02/16^{}

I'm not sure what the ^{} characters at the end of the second tag mean and I want to make sure that this behavior we stumbled upon isn't something we should not be doing before we go and leverage it to clean up our tags.

We don't see the ^{} characters on our "un-nested" tags.

Answer 1

The only problem you'll encounter is an unhelpful error message if you attempt to create a tag that collides with a "directory" in your hierarchy (caused directly by the directories that git uses to store the tags colliding):

% git tag foo/bar
% git tag foo
error: there are still refs under 'refs/tags/foo'
fatal: refs/tags/foo: cannot lock the ref

This is unlikely to be a problem in practice, it normally comes up when people try and do:

v0.0.1/rc1
v0.0.1/rc2
v0.0.1/beta1
v0.0.1/beta2

then, try and tag v0.0.1, which'll hit the above problem.