Determine branch/tag naming restrictions in Git

Since moving to a Git workflow would mean that the sandboxes and each project (at the very least) would be in their own repositories, I think we can get rid of the tagging and branching restrictions. No longer will all of the contributed projects share branches and tags, so the only namespace to pollute is your own.

Of course, the package creator that makes the downloads on d.o should only allow the same tags and branches we have always used. It shouldn't be hard for it to filter out the tags and branches it doesn't recognize.

We were definitely never going to have branch naming restrictions in the issue repos, or in the sandbox repos. I can't remember if there's been a discussion yet about if/how the current restrictions will be moved over to git, nor do I know if there's a reason for the restrictions beyond polluting the global CVS namespace. If not, then I agree - I don't see much reason to do the extra work of writing up scripts that restrict branch naming when we can just filter in the web UI.

Making this into one of the phase 2 items. We've got some other issues open about commit logging and such, but we do need to think about if & how to convert the restrictions we have over to git.

I had an extended conversation with dww about commit, branch and tag naming restrictions last week, and I've been needing to get it posted. A fuller summary will be posted as a reply to this issue soon, but the quick summary version is: no commit restrictions on d.o, except possibly on LICENSE.txt. The structure of a dvcs dictates that 'commit' restrictions actually can _only_ be 'receive' restrictions triggered when the d.o servers receive a push. Which means an arbitrarily large number of commits are being parsed at a time, and if commit 12 in a series of 100 commits violates the commit restrictions, we'd have to reject it all, or at least everything after that commit. To get around the restriction, then, people would have to rewrite history to remove the offending commit. Rewriting history is not a novice operation, and really not an OK thing to ever have a hard structural requirement that people do.

We should open another issue for the discussion of LICENSE.txt specifically and close this issue in anticipation of the summary of that conversation being posted.

Thanks for being my fantasmagastic secretary, Angie :)

This is necessary so that we can support Git's "branch early and often" development model. So there will be no more restrictions on creating feature branches, hotfix branches, or whatever else people want to do. YAY!

Lemme just put a little bit more of my own marketing spin on this, since I think this is huge. For features of any size, and most bugfixes that are more than just a couple quick lines, I tend to use a separate branch. By opening up such branches to the world, it'll let people REALLY unleash the power of a dvcs.

By opening up such branches to the world, it'll let people REALLY unleash the power of a dvcs.

True. And it will also unleash a torrent of very confused branching and "release management" disasters in contrib. ;) But, that's the price we're going to have to live with. Progress isn't necessarily free...

But yes, I'm all in favor of a) the new branch/tag naming conventions for releases (we need an issue open about this in vcapi_project or something), and b) letting it rip for all other uses of branches and tags.

Cheers,
-Derek

Eh. You've got more experience in the area of what people actually do with their VCS freedoms, but I'm hoping we can put enough instructions in place that people will know why only name-conforming branches show up in the UI - and therefore, not too many release management disasters. Though I do agree there'll be a ton of confused branching - fortunately, not really a problem at all in git :)