Latest revision as of 18:34, 18 March 2016

Warning

This page is yet to be reviewed for changes required by the migration to Git. Information and commands on this page may no longer be valid and should be used with care. Please see the KDE Git hub page for more details.

Introduction

This is a tutorial on how we use git for rekonq development, it's not meant to be a git manual.

For information on how git is used and managed inside KDE look here.

Note: In order to use ReviewBoard you need an KDE identity account.

Git for frequent contributions (or patches with more than one commit)

Frequent contributors should have their own repository clone. KDE developers have git.kde.org available and services such as Gitorious can be used by the rest.

This should be the place were all the work is uploaded, and there should be a new branch for every new feature.

When a feature is ready for revision, you should upload a diff to ReviewBoard and indicate the repository and branch where the feature can be found. This way anyone wanting to test it can simply add a new remote.

Once the feature is ready for shipping, you're allowed to push it to the main repository if you have access or you can ask someone to do it for you if you don't. Please rebase the branch beforehand when possible.

Git for one-time simple patches

Simple patches may be uploaded directly to ReviewBoard for revision. A rekonq developer will commit it when necessary.

Note for commiters: When commiting a patch from reviewboard use the --author option to credit the author.

Use a line with REVIEW: # in the commit message - this will close the specific REVIEW on ReviewBoard.

This workflow takes more time to test because testers have to download the diff and apply it manually, so it's only recommended for people that contribute a casual patch and don't plan on working on rekonq in the future.

Commit messages

The commit message is an important part of a patch. It gives context on what is fixed, why, and how for future reference. Reviewers are expected to check the quality of the commit message.

The expected layout is the following:

Short summary, explain what the patch does in one sentense
--empty line--
Complete description of the patch
--empty line--
REVIEW: #
Reviewed by: Name of the reviewer

Example of good commit message of Qt: http://qt.gitorious.org/qt/qt/commit/03bb8fb0af66a24c2b532d2fe6febb426c64f684

Example of bad commit message (no reviewer, no explanation on what was the problem and what is the solution): http://qt.gitorious.org/qt/qt/commit/3526db3b8832c357b368014e6c8ebab63d4071da

Example for REVIEW keyword: http://gitweb.kde.org/amarok.git/commit/5d3b22da211b6897d7dde5b90ac897d2f397bf18 http://git.reviewboard.kde.org/r/100270/