Difference between revisions of "Activity Team/Git Migration"

From Sugar Labs
Jump to navigation Jump to search
m
(→‎See also: add link to cgit)
Line 40: Line 40:
  
 
*A [[Activity Team/Git FAQ|Git/Gitorious FAQ]]
 
*A [[Activity Team/Git FAQ|Git/Gitorious FAQ]]
 +
*[http://cgit.sugarlabs.org/ cgit] interface for git.sugarlabs.org
  
 
[[Category:Development Team]]
 
[[Category:Development Team]]

Revision as of 16:17, 27 June 2009

Import a module from dev.laptop.org

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.

See also