Projects/rekonq/Git with rekonq HowTo - Revision history

Odysseus at 14:10, 1 March 2011

2011-03-01T14:10:19Z

Ei-jo: Add description for using REVIEW keyword

2011-01-26T21:03:14Z

Add description for using REVIEW keyword

Ikipou: Add expected features of a good commit message.

2011-01-16T19:55:37Z

Add expected features of a good commit message.

Felixr: Typo

2011-01-16T12:16:44Z

Typo

Jonanderp: /* Git for frequent contributions (or patches with more than one commit) */

2011-01-16T10:18:15Z

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

Jonanderp: /* Introduction */

2011-01-16T10:17:08Z

‎Introduction

Jonanderp: /* Introduction */

2011-01-16T10:16:57Z

‎Introduction

Jonanderp: Created page with '=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 an manage inside KDE look [htt...'

2011-01-16T10:16:42Z

Created page with '=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 an manage inside KDE look [htt...'

New page

=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 an manage inside KDE look [http://community.kde.org/Sysadmin/GitKdeOrgManual here].

'''Note:''' In other to used [http://git.reviewboard.kde.org ReviewBoard] you need an [http://identity.kde.org/ 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 [http://git.kde.org git.kde.org] available and services such as [http://gitorious.org 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.
Once a feature is ready for revision, you should upload a diff to [http://git.reviewboard.kde.org 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 [http://git.reviewboard.kde.org 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.

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.

← Older revision		Revision as of 14:10, 1 March 2011
Line 1:		Line 1:
		+	{{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 [[Development/Git\|KDE Git hub page]] for more details. }}
		+
	=Introduction=		=Introduction=

@@ Line 22: / Line 22: @@
 '''Note for commiters:''' When commiting a patch from reviewboard use the ''--author'' option to credit the author.
 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.
@@ Line 36: / Line 38: @@
 Complete description of the patch
 --empty line--
-Review Board request: url to the reviewboard request if any
+REVIEW: #
 Reviewed by: Name of the reviewer
 </pre>
@@ Line 43: / Line 45: @@
 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

← Older revision		Revision as of 19:55, 16 January 2011
Line 24:		Line 24:

	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.		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:
		+	<pre>
		+	Short summary, explain what the patch does in one sentense
		+	--empty line--
		+	Complete description of the patch
		+	--empty line--
		+	Review Board request: url to the reviewboard request if any
		+	Reviewed by: Name of the reviewer
		+	</pre>
		+
		+	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

@@ Line 3: / Line 3: @@
 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 an managed inside KDE look [http://community.kde.org/Sysadmin/GitKdeOrgManual here].
+For information on how git is used and managed inside KDE look [http://community.kde.org/Sysadmin/GitKdeOrgManual here].
-'''Note:''' In other to used [http://git.reviewboard.kde.org ReviewBoard] you need an [http://identity.kde.org/ KDE identity] account.
+'''Note:''' In order to use [http://git.reviewboard.kde.org ReviewBoard] you need an [http://identity.kde.org/ KDE identity] account.
 =Git for frequent contributions (or patches with more than one commit)=

@@ Line 3: / Line 3: @@
 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 an manage inside KDE look [http://community.kde.org/Sysadmin/GitKdeOrgManual here].
+For information on how git is used an managed inside KDE look [http://community.kde.org/Sysadmin/GitKdeOrgManual here].
 '''Note:''' In other to used [http://git.reviewboard.kde.org ReviewBoard] you need an [http://identity.kde.org/ KDE identity] account.

@@ Line 12: / Line 12: @@
 This should be the place were all the work is uploaded, and there should be a new branch for every new feature.
-Once a feature is ready for revision, you should upload a diff to [http://git.reviewboard.kde.org 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.

@@ Line 1: / Line 1: @@
 =Introduction=
-This is a tutorial on how we use git for rekonq development, it's not meant to be a Git manual.
+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 an manage inside KDE look [http://community.kde.org/Sysadmin/GitKdeOrgManual here].