Git - Revision history

GNUtoo: /* Pushing changes */

2013-04-08T20:18:11Z

‎Pushing changes

2013-02-18T16:14:15Z

‎Working with Git: fix link

2012-09-24T13:23:35Z

‎Gerrit and CLI

2012-09-14T15:34:09Z

‎Accessing the repository

2012-08-29T04:20:02Z

‎Evolving patches

2012-08-29T04:19:46Z

‎Working with Git

2011-12-25T19:36:58Z

‎Evolving patches

2011-12-15T12:35:42Z

‎Accessing the repository: note that git version must be >= 1.6.6 for http access

2011-12-15T12:30:15Z

‎Commit messages

2011-07-20T09:01:19Z

‎OpenID

← Older revision		Revision as of 20:18, 8 April 2013
Line 114:		Line 114:

	For automating patch submission further (ie. more ways of simplifying the command line), see the last paragraph of [http://review.coreboot.org/Documentation/user-upload.html#push_create this gerrit documentation].		For automating patch submission further (ie. more ways of simplifying the command line), see the last paragraph of [http://review.coreboot.org/Documentation/user-upload.html#push_create this gerrit documentation].
		+
		+	== Pushing Drafts ==
		+	git push origin HEAD:refs/drafts/master

	== Evolving patches ==		== Evolving patches ==

@@ Line 53: / Line 53: @@
 = Working with Git =
-Git is a distributed version control system. This means that you can manage commits and branches completely without restriction in your local clone of the coreboot repository. Peter wrote [http://www.coreboot.org/pipermail/coreboot/2011-June/065427.html a Git introduction] after the switch to Git had been announced on the mailing list.
+Git is a distributed version control system. This means that you can manage commits and branches completely without restriction in your local clone of the coreboot repository. Peter wrote [http://www.coreboot.org/pipermail/coreboot/2011-June/065422.html a Git introduction] after the switch to Git had been announced on the mailing list.
 == Commit messages ==

@@ Line 24: / Line 24: @@
 Reviews normally happens through the website.
-Since gerrit exposes an interface through its ssh daemon, it's also possible to do reviews from CLI or mail. Unfortunately there doesn't seem to be any standing tradition on how to build a workflow around these parts, so we'll document our best practices here once they settled.
+Since gerrit exposes an interface through its ssh daemon, it's also possible to do reviews from CLI or mail. Unfortunately there doesn't seem to be any standing tradition on how to build a workflow around these parts, so we'll document our best practices here once they settled. You can find the official Gerrit documentation about its CLI tools [http://gerrit.googlecode.com/svn/documentation/2.0.34/cmd-index.html here].
 === Gerrit and Email ===

@@ Line 42: / Line 42: @@
   git clone <nowiki>http://[<username>:<password>@]review.coreboot.org/p/coreboot.git</nowiki>
-Inside the checkout you should install the commit-msg hook which prepares commit messages to fit the style required by gerrit. This needs to happen only once per clone and can be done with
+Inside the checkout you should install a commit-msg hook that adds a Change-Id into commit messages, which uniquely identifies the logical change in Gerrit even across multiple iterations of the commit. The hook only needs to be installed once per clone, and installation can be done with
   wget -O .git/hooks/commit-msg <nowiki>http://review.coreboot.org/tools/hooks/commit-msg</nowiki> && \
     chmod +x .git/hooks/commit-msg
-Alternatively, you could also just run
+Or you can also just run
   make gitconfig

@@ Line 127: / Line 127: @@
 Alternatively, you may amend your local commit and push the updated patch to gerrit:
-  git add path/to/updated/file
+  git add <path/to/updated/files>
   git commit --amend

← Older revision		Revision as of 04:19, 29 August 2012
Line 124:		Line 124:

	then commit and push the updated patch.		then commit and push the updated patch.
		+
		+	Alternatively, you may amend your local commit and push the updated patch to gerrit:
		+
		+	git add path/to/updated/file
		+	git commit --amend
		+
		+	then push the updated patch.

	== Further Git reading ==		== Further Git reading ==

@@ Line 119: / Line 119: @@
 Often it might happen that the patch you sent for approval is not good enough from the first attempt. Gerrit and git make it easy to track patch evolution during the review process until patches meet our quality standards and are ready for approval.
-You can easily modify a patch sent to gerrit by you or even by someone else. Just apply it locally using one of the possible ways to do it, make a new local commit that fixes the issues reported by the reviewers, then rebase the change by preserving the same Change-ID. We recommend you to use the git rebase command in interactive mode, ''git rebase -i master'', then commit and push the updated patch.
+You can easily modify a patch sent to gerrit by you or even by someone else. Just apply it locally using one of the possible ways to do it, make a new local commit that fixes the issues reported by the reviewers, then rebase the change by preserving the same Change-ID. We recommend you to use the git rebase command in interactive mode,
 == Further Git reading ==

@@ Line 36: / Line 36: @@
 = Accessing the repository =
-The repository can be accessed using ssh (with public key authentication) or http (anonymous read-only or read-write using user/password authentication). The latter is particularily interesting for people behind firewalls. The http password can be generated (and regenerated if necessary) at http://review.coreboot.org/#settings,http-password.
+The repository can be accessed using ssh (with public key authentication) or http (anonymous read-only or read-write using user/password authentication). The latter is particularily interesting for people behind firewalls, but requires git to be version 1.6.6 or newer (for "Smart HTTP" transfer). The http password can be generated (and regenerated if necessary) at http://review.coreboot.org/#settings,http-password.
   git clone ssh://<username>@review.coreboot.org:29418/coreboot

← Older revision		Revision as of 12:30, 15 December 2011
Line 77:		Line 77:

	The example is missing a Change-Id: line. This is OK because Joe Hacker has set up the commit-msg hook [[#Authenticated_read/write_access\|as mentioned above]], which adds a Change-Id: automatically when the commit message is saved.		The example is missing a Change-Id: line. This is OK because Joe Hacker has set up the commit-msg hook [[#Authenticated_read/write_access\|as mentioned above]], which adds a Change-Id: automatically when the commit message is saved.
		+
		+	=== Guidelines on commit message content ===
		+
		+	* If anyone involved in coreboot reads your comment in a year, she/he shall still be able to understand what your commit is about, without analyzing the code.
		+	* Double-check that you're really committing what you think you are, e.g. by typing the following in the top-level coreboot directory:
		+	git show

	== Pushing changes ==		== Pushing changes ==

@@ Line 7: / Line 7: @@
 === OpenID ===
-It seems that gerrit is picky about the OpenID format. Always provide a full URL, including protocol (ie. http:// or https:// prefix). Unfortunately the error messages are non-intuitive.
+It seems that gerrit is picky about the OpenID format. Always provide a full URL, including protocol (ie. http:// or https:// prefix). Unfortunately the error messages are non-intuitive (but will improve in the future)
 == Gerrit workflow ==