2012-02-17 49 views
10

我们在我们的git仓库上创建了一个标签“2012/02/16”。然后我们注意到,在Source Tree内部,2012和01被表示为可以整齐地打开和关闭以显示和隐藏标签的文件夹。拥有嵌套的标签层次结构似乎是组织标签的一种不错方式,而不仅仅是一个扁平列表。在git标签名称中添加“/”以创建分层/嵌套标签是否存在问题?

这样做有问题吗?

当我做一个git LS-远程I看到以下条目:

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

我不知道是什么在第二个标签的末尾^ {}字符的意思是,我要确保我们偶然发现的这种行为并不是我们在去之前不应该做的事情,而是利用它来清理我们的标签。

我们看不到我们的“未嵌套”标签上的^ {}字符。

+3

'^ {}'是递归引用标签的简写语法,直到找到非标签对象为止。如果您没有在其他代码上看到它,那可能意味着您的其他代码是轻量级代码而不是注释代码。 – 2012-02-17 04:13:31

回答

8

没问题,使用斜杠是标准做法,例如在“git-flow”规范中。你可以在手册页检查标签名的语法规则git-check-ref-format(1): http://schacon.github.com/git/git-check-ref-format.html

括号里的插入符号是git试图告诉你的那个标签,而不是你键入的东西。您可以使用手册页gitrevisions(7)解释它: http://schacon.github.com/git/gitrevisions.html

+0

OP的注意事项:使用斜杠非常好,你可以将它想象为嵌套,但是没有任何git命令会将你的标记集作为一个层次结构。这就是他们碰巧存储的方式。 – Cascabel 2012-02-17 05:50:50

10

,你会遇到的唯一问题是无益的错误信息,如果你试图创建与您的层次结构中的“目录”碰撞的标签(由于直接由Git使用存储碰撞的标签)的目录:

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

这是不太可能在实践中的问题,它通常出现在当人们试图做:

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

然后,尝试和标签v0.0.1,这会遇到上述问题。

+0

非常感谢!我有一个标签为“1.3.39/40”的提交,并试图将其重新标记为1.3.39和1.3.40,因此我输入了'git tag 1.3.39 -am“Version 1.3 Revision 39”1.3.39/40 '并得到这个错误。只需用斜杠删除标签,然后通过提供提交哈希来添加新标签即可解决问题。 – Dan 2014-12-08 16:27:07

1

除了文件/目录冲突问题,还有一个可以遇到的区分大小写问题。如果您运行的是Windows和Mac OS X等不区分大小写的文件系统,则可能在远程存储库上存在无法读取/拉取的标签。例如下面会发生冲突:

archive/some-tag-or-other 
Archive/a-different-tag 

当混帐创建它居然把在.git/refs/tags/archive目录获取第二标签。一旦你进入该状态,后续的提取/提取将不断尝试重新获得第二个标签。

但是,有一个简单的解决方法,即运行git pack-refs,它将单个ref文件合并到纯文本文件.git/packed-refs中。一旦运行完第一个标签的单个标签文件将与.git/refs/tags/archive目录一起被删除,那么第二个标签可以成功获取/拉出。

+0

与问题无关。标签'Some-tag'和'some-tag'会导致同样的事情,而不涉及任何文件夹。 – Chronial 2013-07-11 11:13:09