Существуют ли проблемы с добавлением «/» в имя тега git для создания иерархических / вложенных тегов?

Question

Мы создали тег «2012/02/16» в нашем репозитории git.Затем мы заметили, что внутри исходного дерева 2012 и 01 были представлены в виде папок, которые можно аккуратно открывать и закрывать, чтобы открывать и скрывать теги.Наличие вложенной иерархии тегов кажется хорошим способом упорядочить теги, а не просто иметь один плоский список.

Есть ли проблема с этим?

Когда я делаю git ls-Удаленный Я вижу следующие записи:

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

Я не уверен, что означают символы ^ {} в конце второго тега, и я хочу убедиться, что это поведение, на которое мы наткнулись, нечто-то, что мы не должны делать, прежде чем использовать его для очистки наших тегов.

Мы не видим символов ^ {} в наших "не вложенных" тегах.

Answer 1

Единственная проблема, с которой вы столкнетесь, - это бесполезное сообщение об ошибке, если вы попытаетесь создать тег, который сталкивается с «каталогом» в вашей иерархии (вызванный непосредственно каталогами, которые 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, что поможет решить вышеуказанную проблему.

Answer 2

Нет проблем, использование косой черты является стандартной практикой, например, в дисциплине «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

Answer 3

Наряду с проблемой коллизии файлов / каталогов существует также проблема чувствительности к регистру, с которой вы можете столкнуться. Если вы работаете в нечувствительной к регистру файловой системе, такой как Windows и Mac OS X, то в удаленном репозитории можно иметь теги, которые вы не можете получить / извлечь. Например, следующее будет конфликтовать:

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

как и когда git создает второй тег, он фактически помещается в каталог .git/refs/tags/archive. Как только вы окажетесь в этом состоянии, последующие выборки / извлечения будут постоянно пытаться повторно получить второй тег.

Однако для этого есть простой обходной путь, который заключается в запуске git pack-refs, которая объединяет отдельные файлы ссылок в простой текстовый файл .git/packed-refs. Как только вы запустите, отдельный файл тега для первого тега будет удален вместе с каталогом .git/refs/tags/archive, тогда второй тег может быть успешно извлечен / извлечен.