This project's repository contains both a 7.x-2.x branch and a 7.x-2.x tag.

7.x-2.x is an invalid name for a tag. This tag should be deleted.

Branch and tag naming standards:
http://drupal.org/node/1015226

Instructions for deleting tags:
http://drupal.org/node/1066342

Comments

sreynen’s picture

Is the tag actually causing a problem or does it just look wrong? http://drupal.org/node/1015226 mentions limitations on release tags, but I'm not aware of any restrictions on tags in general.

TR’s picture

A little background as to how I found this:
I wrote a script to download the repository and checkout the highest-version minor branch of each project for D7. Because the script can't know ahead of time what branches exist, it has to do a git clone http://git.drupal.org/projects/project_name.git, then a git branch -a, then parse the branch names and git checkout branchname. If a tag has the same name as the branch, this results in a checkout of the *tag* instead of the branch.

Git doesn't prevent this, but in general you can get into big trouble if you name branches and tags the same. Different git commands make different assumptions about what you mean when you use "7.x-2.x" to identify the object. There's no ambiguity if you always refer to the tag as refs/tags/7.x-2.x and always refer to the branch as refs/heads/7.x-2.x, but in practice what everyone does is something like git checkout 7.x-2.x, which will give you the *tag* 7.x-2.x instead of the branch.

Following the examples in the "Version control" tab:

git clone --branch 7.x-2.x http://git.drupal.org/project/google_fonts.git
cd google_fonts

Now you're on *branch* 7.x-2.x. But try git checkout 7.x-2.x and not only will you get a warning:

warning: refname '7.x-2.x' is ambiguous.
Already on '7.x-2.x'

But if you now type git status you will see:

# On branch 7.x-2.x
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   google_fonts.admin.inc
#	modified:   google_fonts.install
#	modified:   google_fonts.module
#

git diff --staged shows you that the checkout has put you onto the *tag* 7.x-2.x, even though git status is telling you you're on the *branch* 7.x-2.x.

If however we checkout the project a different way, and instead of git clone --branch we just do:

git clone http://git.drupal.org/project/google_fonts.git
cd google_fonts
git checkout 7.x-2.x

Now we will be left on *tag* 7.x-2.x instead of *branch* 7.x-2.x.

Fixing this situation by renaming the tag can be a problem too, because it's ambiguous what you're trying to rename ...

So while you may be technically correct that Drupal doesn't impose standards on the naming of non-release branches or tags, I think having branches and tags with the same name is a very very bad idea. While the project owner might be fully aware of the situation and how to deal with the ambiguity(*), others who check out this project will be blissfully UNaware until it bites them hard.

(*) In practice, I think having a branch and tag with the same name is the result of an *error* by the project owner, in which case even the project owner might now be aware of the situation. I don't think anyone *intentionally* does this, especially if they have ever had to deal with some of the problems it causes.