Activity Team/Git Migration
< Activity Team
Revision as of 00:38, 13 March 2009 by Homunq (talk | contribs) (→Import a module from dev.laptop.org)
Import a module from dev.laptop.org
- Create an account on http://git.sugarlabs.org
- Log in and create a new project from the projects page (please use only lower case, e.g. sugar, turtleart, sugar-toolkit).
- Clone your git module from dev.laptop.org, e.g.
git clone git://dev.laptop.org/projects/pippy-activity
- See all the remote branches with:
git remote show origin
- Check out the remote branches you want to migrate, e.g.
git checkout -b sucrose-0.82 origin/sucrose-0.82
- Push it to git.sugarlabs.org with something like:
git push gitorious@git.sugarlabs.org:pippy-activity/mainline.git --mirror
- Add the pootle user as a committer (from the "add committer" link on the mainline page) and send mail to Sayamindu, to point pootle to new remote.
- Notify sugar-devel about the move.
- Make sure that sugar-jhbuild points to the new repository (ask someone to do it for you if you have no access)
Clone a module from git.sugarlabs.org
Instructions on how to clone a project from the git repositories of sugarlabs.org can be found at the project's repos/mainline page, for example for sugar-jhbuild. And here is an example:
git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
Git commit message guidelines
These are guidelines to enhance the readability of the commit messages and the release notes which are made with git-shortlog. Please try to follow them as much as possible and make suggestions in the sugar devel mailing list of you find things missing, the guidelines completely insane or just want to demonstrate your appreciation.
- The commit message should start with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. Tools that turn commits into email, for example, use the first line on the Subject: line and the rest of the commit in the body. The git-shortlog command that we use to write the release notes will strip the more detailed description.
- If your commit does fix a certain bug make sure that the summarizing line contains the bug number prepended by a '#' at the end of the line (e.g. #14). It is implied that you mean the Sugar Labs trac instance. If not please prepend an identifier like OLPC#123, RH#456, Debian#666, Ubuntu#53.
- Start your commit message with a capital letter.
- Suffix no dot at the end of the summarizing line.
- Fixes for typing errors and pylint fixes happen quite often. Just mark them _Typo and respectively _Pylint for easier reading.