Dear coreboot developers, stakeholders, and enthusiasts,
I'm glad to be able to announce that we moved the repository infrastructure to git and gerrit, with jenkins as supporting facility.
This was done with the goal of improving the development workflow, meaning less overhead for developers when managing the patch queue. This should lead to losing fewer patch submissions.
So far we used patchwork[1], but it's more maintenance work than practical given that it requires manual handling of patches that don't match the commit diff, and of patches that went through multiple iterations. While it improved the visibility of patches (and I'm thankful for that), it still posed a higher than necessary barrier to patch review.
Gerrit[2] is a code review utility developed by Google which uses the distributed properties of git to provide a seamless path for patches from submission to commit.
For this, git[3] is used: Gerrit uses its ability to create and tear down branches as necessary to push every contribution into its own branch. This way it's already "tracked" by the version control system without influencing the master branch.
The use of git also plays well into the desire of several coreboot contributors to switch from svn to git.
In addition to these changes, we also moved the build bot from our own custom build variant to a more standard Jenkins[4] installation. In addition to building commits after they are integrated on the master branch ("trunk" in SVN terminology), it's also configured to build patch submissions on gerrit as they come in. That way there's automated feedback on a patch before spending time on it.
All this means that the coreboot development workflow changes considerably:
1. New SCM You will need git, so install it from your usual software distribution channels.
For patch submission a gerrit account is necessary. You can register it on http://review.coreboot.org. With the account you can also review patches. The ability to merge patches to mainline will be granted by admins.
ssh public keys are used for authentication. You can register them with gerrit in your user preferences at http://review.coreboot.org/#settings when logged in.
Gerrit requires that the commit message contains Change-Id: lines. "make gitconfig" inside a coreboot checkout installs a commit message handler which takes care of this.
The committer address must match an email address that is registered with your gerrit acccount. Again these can be configured in gerrit user preferences.
Fetching anonymously: git clone http://review.coreboot.org/p/coreboot Fetching authenticated: git clone ssh://<username>@review.coreboot.org:29418/coreboot
2. New patch submission process Develop "as usual" in git, and commit freely. When you're ready to submit patches, push them with git push origin HEAD:refs/for/master
This will tell gerrit which branch your commits are for (master) and it will create internal branches for each commit you pushed, making them separate changesets. If you push a number of commits at once, they're properly linked as "dependencies", so people (and tools like gerrit and jenkins) are aware about prerequisites.
For automating some aspects of patch submission, see the last paragraph of http://review.coreboot.org/Documentation/user-upload.html#push_create
We will also document more of making live easier at http://www.coreboot.org/Git as best practices are established.
3. New patch review process The main interface to do patch reviews is the gerrit webapp at http://review.coreboot.org. For those who tend to avoid web apps, there's the option of controlling gerrit via ssh. Detailed information on that will be posted at http://www.coreboot.org/Git. There's no real workflow defined around this interface yet because it seems to be an unpopular choice as _User_ Interface. This means, we'll have to develop our own.
4. Mail notification Mail notification to the mailing list is implemented from scratch. Right now it only reports on new patch submissions and on patches merged into the master branch. More events might/will follow in future, and we will certainly tweak the ad-hoc messages and formatting some more.
Questions? Comments? Praise? Flames? Patrick
[1] http://ozlabs.org/~jk/projects/patchwork [2] http://gerrit.googlecode.com [3] http://git-scm.com/ [4] http://jenkins-ci.org/
On Sun, Jun 5, 2011 at 4:48 PM, Patrick Georgi patrick@georgi-clan.de wrote:
Dear coreboot developers, stakeholders, and enthusiasts,
I'm glad to be able to announce that we moved the repository infrastructure to git and gerrit, with jenkins as supporting facility.
This was done with the goal of improving the development workflow, meaning less overhead for developers when managing the patch queue. This should lead to losing fewer patch submissions.
So far we used patchwork[1], but it's more maintenance work than practical given that it requires manual handling of patches that don't match the commit diff, and of patches that went through multiple iterations. While it improved the visibility of patches (and I'm thankful for that), it still posed a higher than necessary barrier to patch review.
Gerrit[2] is a code review utility developed by Google which uses the distributed properties of git to provide a seamless path for patches from submission to commit.
For this, git[3] is used: Gerrit uses its ability to create and tear down branches as necessary to push every contribution into its own branch. This way it's already "tracked" by the version control system without influencing the master branch.
The use of git also plays well into the desire of several coreboot contributors to switch from svn to git.
In addition to these changes, we also moved the build bot from our own custom build variant to a more standard Jenkins[4] installation. In addition to building commits after they are integrated on the master branch ("trunk" in SVN terminology), it's also configured to build patch submissions on gerrit as they come in. That way there's automated feedback on a patch before spending time on it.
All this means that the coreboot development workflow changes considerably:
- New SCM
You will need git, so install it from your usual software distribution channels.
For patch submission a gerrit account is necessary. You can register it on http://review.coreboot.org. With the account you can also review patches. The ability to merge patches to mainline will be granted by admins.
ssh public keys are used for authentication. You can register them with gerrit in your user preferences at http://review.coreboot.org/#settings when logged in.
Gerrit requires that the commit message contains Change-Id: lines. "make gitconfig" inside a coreboot checkout installs a commit message handler which takes care of this.
The committer address must match an email address that is registered with your gerrit acccount. Again these can be configured in gerrit user preferences.
Fetching anonymously: git clone http://review.coreboot.org/p/coreboot Fetching authenticated: git clone ssh://<username>@review.coreboot.org:29418/coreboot
- New patch submission process
Develop "as usual" in git, and commit freely. When you're ready to submit patches, push them with git push origin HEAD:refs/for/master
This will tell gerrit which branch your commits are for (master) and it will create internal branches for each commit you pushed, making them separate changesets. If you push a number of commits at once, they're properly linked as "dependencies", so people (and tools like gerrit and jenkins) are aware about prerequisites.
For automating some aspects of patch submission, see the last paragraph of http://review.coreboot.org/Documentation/user-upload.html#push_create
We will also document more of making live easier at http://www.coreboot.org/Git as best practices are established.
- New patch review process
The main interface to do patch reviews is the gerrit webapp at http://review.coreboot.org. For those who tend to avoid web apps, there's the option of controlling gerrit via ssh. Detailed information on that will be posted at http://www.coreboot.org/Git. There's no real workflow defined around this interface yet because it seems to be an unpopular choice as _User_ Interface. This means, we'll have to develop our own.
- Mail notification
Mail notification to the mailing list is implemented from scratch. Right now it only reports on new patch submissions and on patches merged into the master branch. More events might/will follow in future, and we will certainly tweak the ad-hoc messages and formatting some more.
Questions? Comments? Praise? Flames? Patrick
[1] http://ozlabs.org/~jk/projects/patchwork [2] http://gerrit.googlecode.com [3] http://git-scm.com/ [4] http://jenkins-ci.org/
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hello! I have one. What would prompt this to happen? root@jimkirk2:/usr/src/lobos# git clone http://review.coreboot.org/p/coreboot Initialized empty Git repository in /usr/src/lobos/coreboot/.git/ fatal: http://review.coreboot.org/p/coreboot/info/refs download error - The requested URL returned error: 403 root@jimkirk2:/usr/src/lobos#
That's from my first efforts to clone the recently configured repository.
----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again."
On Mon, Jun 6, 2011 at 00:17, Gregg Levine gregg.drwho8@gmail.com wrote:
On Sun, Jun 5, 2011 at 4:48 PM, Patrick Georgi patrick@georgi-clan.de wrote:
Dear coreboot developers, stakeholders, and enthusiasts,
I'm glad to be able to announce that we moved the repository infrastructure to git and gerrit, with jenkins as supporting facility.
This was done with the goal of improving the development workflow, meaning less overhead for developers when managing the patch queue. This should lead to losing fewer patch submissions.
So far we used patchwork[1], but it's more maintenance work than practical given that it requires manual handling of patches that don't match the commit diff, and of patches that went through multiple iterations. While it improved the visibility of patches (and I'm thankful for that), it still posed a higher than necessary barrier to patch review.
Gerrit[2] is a code review utility developed by Google which uses the distributed properties of git to provide a seamless path for patches from submission to commit.
For this, git[3] is used: Gerrit uses its ability to create and tear down branches as necessary to push every contribution into its own branch. This way it's already "tracked" by the version control system without influencing the master branch.
The use of git also plays well into the desire of several coreboot contributors to switch from svn to git.
In addition to these changes, we also moved the build bot from our own custom build variant to a more standard Jenkins[4] installation. In addition to building commits after they are integrated on the master branch ("trunk" in SVN terminology), it's also configured to build patch submissions on gerrit as they come in. That way there's automated feedback on a patch before spending time on it.
All this means that the coreboot development workflow changes considerably:
- New SCM
You will need git, so install it from your usual software distribution channels.
For patch submission a gerrit account is necessary. You can register it on http://review.coreboot.org. With the account you can also review patches. The ability to merge patches to mainline will be granted by admins.
ssh public keys are used for authentication. You can register them with gerrit in your user preferences at http://review.coreboot.org/#settings when logged in.
Gerrit requires that the commit message contains Change-Id: lines. "make gitconfig" inside a coreboot checkout installs a commit message handler which takes care of this.
The committer address must match an email address that is registered with your gerrit acccount. Again these can be configured in gerrit user preferences.
Fetching anonymously: git clone http://review.coreboot.org/p/coreboot Fetching authenticated: git clone ssh://<username>@review.coreboot.org:29418/coreboot
- New patch submission process
Develop "as usual" in git, and commit freely. When you're ready to submit patches, push them with git push origin HEAD:refs/for/master
This will tell gerrit which branch your commits are for (master) and it will create internal branches for each commit you pushed, making them separate changesets. If you push a number of commits at once, they're properly linked as "dependencies", so people (and tools like gerrit and jenkins) are aware about prerequisites.
For automating some aspects of patch submission, see the last paragraph of http://review.coreboot.org/Documentation/user-upload.html#push_create
We will also document more of making live easier at http://www.coreboot.org/Git as best practices are established.
- New patch review process
The main interface to do patch reviews is the gerrit webapp at http://review.coreboot.org. For those who tend to avoid web apps, there's the option of controlling gerrit via ssh. Detailed information on that will be posted at http://www.coreboot.org/Git. There's no real workflow defined around this interface yet because it seems to be an unpopular choice as _User_ Interface. This means, we'll have to develop our own.
- Mail notification
Mail notification to the mailing list is implemented from scratch. Right now it only reports on new patch submissions and on patches merged into the master branch. More events might/will follow in future, and we will certainly tweak the ad-hoc messages and formatting some more.
Questions? Comments? Praise? Flames? Patrick
[1] http://ozlabs.org/~jk/projects/patchwork [2] http://gerrit.googlecode.com [3] http://git-scm.com/ [4] http://jenkins-ci.org/
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hello! I have one. What would prompt this to happen? root@jimkirk2:/usr/src/lobos# git clone http://review.coreboot.org/p/coreboot Initialized empty Git repository in /usr/src/lobos/coreboot/.git/ fatal: http://review.coreboot.org/p/coreboot/info/refs download error
- The requested URL returned error: 403
root@jimkirk2:/usr/src/lobos#
That's from my first efforts to clone the recently configured repository.
Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again."
That's odd. First of all: worksforme(tm). This message should only appear when you do a "git init", not for a "git clone" Maybe the path "/usr/src/lobos/coreboot" already exists? Highly unlikely that this would cause this behavior, but if so, try to remove the coreboot dir or chose another destination.
On Sun, Jun 5, 2011 at 6:24 PM, Thomas Gstädtner thomas@gstaedtner.net wrote:
On Mon, Jun 6, 2011 at 00:17, Gregg Levine gregg.drwho8@gmail.com wrote:
On Sun, Jun 5, 2011 at 4:48 PM, Patrick Georgi patrick@georgi-clan.de wrote:
Dear coreboot developers, stakeholders, and enthusiasts,
I'm glad to be able to announce that we moved the repository infrastructure to git and gerrit, with jenkins as supporting facility.
This was done with the goal of improving the development workflow, meaning less overhead for developers when managing the patch queue. This should lead to losing fewer patch submissions.
So far we used patchwork[1], but it's more maintenance work than practical given that it requires manual handling of patches that don't match the commit diff, and of patches that went through multiple iterations. While it improved the visibility of patches (and I'm thankful for that), it still posed a higher than necessary barrier to patch review.
Gerrit[2] is a code review utility developed by Google which uses the distributed properties of git to provide a seamless path for patches from submission to commit.
For this, git[3] is used: Gerrit uses its ability to create and tear down branches as necessary to push every contribution into its own branch. This way it's already "tracked" by the version control system without influencing the master branch.
The use of git also plays well into the desire of several coreboot contributors to switch from svn to git.
In addition to these changes, we also moved the build bot from our own custom build variant to a more standard Jenkins[4] installation. In addition to building commits after they are integrated on the master branch ("trunk" in SVN terminology), it's also configured to build patch submissions on gerrit as they come in. That way there's automated feedback on a patch before spending time on it.
All this means that the coreboot development workflow changes considerably:
- New SCM
You will need git, so install it from your usual software distribution channels.
For patch submission a gerrit account is necessary. You can register it on http://review.coreboot.org. With the account you can also review patches. The ability to merge patches to mainline will be granted by admins.
ssh public keys are used for authentication. You can register them with gerrit in your user preferences at http://review.coreboot.org/#settings when logged in.
Gerrit requires that the commit message contains Change-Id: lines. "make gitconfig" inside a coreboot checkout installs a commit message handler which takes care of this.
The committer address must match an email address that is registered with your gerrit acccount. Again these can be configured in gerrit user preferences.
Fetching anonymously: git clone http://review.coreboot.org/p/coreboot Fetching authenticated: git clone ssh://<username>@review.coreboot.org:29418/coreboot
- New patch submission process
Develop "as usual" in git, and commit freely. When you're ready to submit patches, push them with git push origin HEAD:refs/for/master
This will tell gerrit which branch your commits are for (master) and it will create internal branches for each commit you pushed, making them separate changesets. If you push a number of commits at once, they're properly linked as "dependencies", so people (and tools like gerrit and jenkins) are aware about prerequisites.
For automating some aspects of patch submission, see the last paragraph of http://review.coreboot.org/Documentation/user-upload.html#push_create
We will also document more of making live easier at http://www.coreboot.org/Git as best practices are established.
- New patch review process
The main interface to do patch reviews is the gerrit webapp at http://review.coreboot.org. For those who tend to avoid web apps, there's the option of controlling gerrit via ssh. Detailed information on that will be posted at http://www.coreboot.org/Git. There's no real workflow defined around this interface yet because it seems to be an unpopular choice as _User_ Interface. This means, we'll have to develop our own.
- Mail notification
Mail notification to the mailing list is implemented from scratch. Right now it only reports on new patch submissions and on patches merged into the master branch. More events might/will follow in future, and we will certainly tweak the ad-hoc messages and formatting some more.
Questions? Comments? Praise? Flames? Patrick
[1] http://ozlabs.org/~jk/projects/patchwork [2] http://gerrit.googlecode.com [3] http://git-scm.com/ [4] http://jenkins-ci.org/
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hello! I have one. What would prompt this to happen? root@jimkirk2:/usr/src/lobos# git clone http://review.coreboot.org/p/coreboot Initialized empty Git repository in /usr/src/lobos/coreboot/.git/ fatal: http://review.coreboot.org/p/coreboot/info/refs download error
- The requested URL returned error: 403
root@jimkirk2:/usr/src/lobos#
That's from my first efforts to clone the recently configured repository.
Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again."
That's odd. First of all: worksforme(tm). This message should only appear when you do a "git init", not for a "git clone" Maybe the path "/usr/src/lobos/coreboot" already exists? Highly unlikely that this would cause this behavior, but if so, try to remove the coreboot dir or chose another destination.
Hello! Actually there was indeed a checked out directory present. It complained and I first moved over with a new name attached. Then repeated the statement. Twice in fact.
Since I usually synch my working directory with what is present on the site on a Sunday, I am going to wait a week and try again.
----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again."
Gregg Levine wrote:
What would prompt this to happen? root@jimkirk2:/usr/src/lobos# git clone http://review.coreboot.org/p/coreboot Initialized empty Git repository in /usr/src/lobos/coreboot/.git/ fatal: http://review.coreboot.org/p/coreboot/info/refs download error
- The requested URL returned error: 403
root@jimkirk2:/usr/src/lobos#
I'm not sure why you get this error.
I can successfully clone using the exact same command.
I can however also confirm that I get a HTTP 403 error on the URL shown in the error message. I guess the version of Git that you are using requests different things from the server than my version.
I am using version 1.7.4.1 with success. Which version are you using?
If your Git version is older than 1.6.6 then please upgrade to a version >= 1.6.6, since that version gained significant performance improvements specifically when using HTTP.
//Peter
On Sun, Jun 5, 2011 at 6:32 PM, Peter Stuge peter@stuge.se wrote:
Gregg Levine wrote:
What would prompt this to happen? root@jimkirk2:/usr/src/lobos# git clone http://review.coreboot.org/p/coreboot Initialized empty Git repository in /usr/src/lobos/coreboot/.git/ fatal: http://review.coreboot.org/p/coreboot/info/refs download error
- The requested URL returned error: 403
root@jimkirk2:/usr/src/lobos#
I'm not sure why you get this error.
I can successfully clone using the exact same command.
I can however also confirm that I get a HTTP 403 error on the URL shown in the error message. I guess the version of Git that you are using requests different things from the server than my version.
I am using version 1.7.4.1 with success. Which version are you using?
If your Git version is older than 1.6.6 then please upgrade to a version >= 1.6.6, since that version gained significant performance improvements specifically when using HTTP.
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hello! Peter the system that everything is hosted on, is wearing version 1.6.1.3 and the test system (same distribution) is wearing 1.7.1.
I am making plans, perhaps further decisions to upgrade to that release. There are specific issues involved with doing so as all of us can imagine. (I'm running Slackware Linux here.) ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again."
Am Sonntag, den 05.06.2011, 18:38 -0400 schrieb Gregg Levine:
On Sun, Jun 5, 2011 at 6:32 PM, Peter Stuge peter@stuge.se wrote:
Gregg Levine wrote:
What would prompt this to happen? root@jimkirk2:/usr/src/lobos# git clone http://review.coreboot.org/p/coreboot Initialized empty Git repository in /usr/src/lobos/coreboot/.git/ fatal: http://review.coreboot.org/p/coreboot/info/refs download error
- The requested URL returned error: 403
root@jimkirk2:/usr/src/lobos#
I'm not sure why you get this error.
I can successfully clone using the exact same command.
I can however also confirm that I get a HTTP 403 error on the URL shown in the error message. I guess the version of Git that you are using requests different things from the server than my version.
I am using version 1.7.4.1 with success. Which version are you using?
If your Git version is older than 1.6.6 then please upgrade to a version >= 1.6.6, since that version gained significant performance improvements specifically when using HTTP.
Peter the system that everything is hosted on, is wearing version 1.6.1.3 and the test system (same distribution) is wearing 1.7.1.
Is it working for you using Git 1.7.1?
[…]
Thanks,
Paul
On Sun, Jun 5, 2011 at 6:54 PM, Paul Menzel paulepanter@users.sourceforge.net wrote:
Am Sonntag, den 05.06.2011, 18:38 -0400 schrieb Gregg Levine:
On Sun, Jun 5, 2011 at 6:32 PM, Peter Stuge peter@stuge.se wrote:
Gregg Levine wrote:
What would prompt this to happen? root@jimkirk2:/usr/src/lobos# git clone http://review.coreboot.org/p/coreboot Initialized empty Git repository in /usr/src/lobos/coreboot/.git/ fatal: http://review.coreboot.org/p/coreboot/info/refs download error
- The requested URL returned error: 403
root@jimkirk2:/usr/src/lobos#
I'm not sure why you get this error.
I can successfully clone using the exact same command.
I can however also confirm that I get a HTTP 403 error on the URL shown in the error message. I guess the version of Git that you are using requests different things from the server than my version.
I am using version 1.7.4.1 with success. Which version are you using?
If your Git version is older than 1.6.6 then please upgrade to a version >= 1.6.6, since that version gained significant performance improvements specifically when using HTTP.
Peter the system that everything is hosted on, is wearing version 1.6.1.3 and the test system (same distribution) is wearing 1.7.1.
Is it working for you using Git 1.7.1?
[…]
Thanks,
Paul
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hello! It in all probability will do so, but I have not tried as such.
This is my one complaint against just git, it is the only source control method that has a strange learning curve. ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again."
On Sun, Jun 5, 2011 at 6:54 PM, Paul Menzel paulepanter@users.sourceforge.net wrote:
Am Sonntag, den 05.06.2011, 18:38 -0400 schrieb Gregg Levine:
On Sun, Jun 5, 2011 at 6:32 PM, Peter Stuge peter@stuge.se wrote:
Gregg Levine wrote:
What would prompt this to happen? root@jimkirk2:/usr/src/lobos# git clone http://review.coreboot.org/p/coreboot Initialized empty Git repository in /usr/src/lobos/coreboot/.git/ fatal: http://review.coreboot.org/p/coreboot/info/refs download error
- The requested URL returned error: 403
root@jimkirk2:/usr/src/lobos#
I'm not sure why you get this error.
I can successfully clone using the exact same command.
I can however also confirm that I get a HTTP 403 error on the URL shown in the error message. I guess the version of Git that you are using requests different things from the server than my version.
I am using version 1.7.4.1 with success. Which version are you using?
If your Git version is older than 1.6.6 then please upgrade to a version >= 1.6.6, since that version gained significant performance improvements specifically when using HTTP.
Peter the system that everything is hosted on, is wearing version 1.6.1.3 and the test system (same distribution) is wearing 1.7.1.
Is it working for you using Git 1.7.1?
[…]
Thanks,
Paul
Hello! And here we are. I've successfully built the version of git that Peter and I were discussing both here, and in a separate but related thread.
And then found in my bash history cycle the original problem that caused this thread. It worked and the problem is gone.
The one question that remains is one of, how do I go about updating a properly cloned download from a git repository? ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again."
Gregg Levine wrote:
how do I go about updating a properly cloned download from a git repository?
I recommend using:
git pull --rebase
git pull first does git fetch, then it does either git merge or git rebase. Which of the second to use only matters if you have changes committed to the local master branch. git merge creates a merge commit to include these changes into the master branch. git rebase will "unhook" the string of commands that you have made, update to whatever the latest is on the coreboot.org server, and finally try to re-apply the string of commits that you had made. Usually this will be completely automatic, but if there are severe conflicting changes (your local changes vs. the changes coming from coreboot.org) then you will have to do manual conflict resolution.
//Peter
Gregg Levine wrote:
What would prompt this to happen? root@jimkirk2:/usr/src/lobos# git clone http://review.coreboot.org/p/coreboot Initialized empty Git repository in /usr/src/lobos/coreboot/.git/ fatal: http://review.coreboot.org/p/coreboot/info/refs download error
- The requested URL returned error: 403
..
I guess the version of Git that you are using requests different things from the server than my version.
..
Peter the system that everything is hosted on, is wearing version 1.6.1.3 and the test system (same distribution) is wearing 1.7.1.
I understand. Version 1.6.1.3 is from February 2009, so is rather old.
I am making plans, perhaps further decisions to upgrade to that release. There are specific issues involved with doing so as all of us can imagine. (I'm running Slackware Linux here.)
It might be possible for you to upgrade only the git package, without needing to upgrade the full distribution.
When I ran Slackware I could download a newer package, such as:
http://slackware.mirrors.easynews.com/linux/slackware/slackware-13.37/slackw...
And then simply run
upgradepkg git-1.7.4.4-i486-1.txz
But I do not know if this still works. Could be worth a try!
//Peter
2011/6/6 Patrick Georgi patrick@georgi-clan.de:
Dear coreboot developers, stakeholders, and enthusiasts,
I'm glad to be able to announce that we moved the repository infrastructure to git and gerrit, with jenkins as supporting facility.
That's absolutely great! Do you plan to switch other projects to new infrastructure as well? I mean flashrom / superiotool / ectool and others.
Am Montag, den 06.06.2011, 07:38 +0400 schrieb Peter Lemenkov:
Do you plan to switch other projects to new infrastructure as well? I mean flashrom / superiotool / ectool and others.
superiotool and ectool are part of the coreboot tree, so these are moved over already.
flashrom is a separate project (with separate repository for a year or two). They can move if and when they want, but they can just as well continue to use their current setup. That's up to them and I won't interfere in that decision.
Patrick
Patrick Georgi wrote:
superiotool and ectool are part of the coreboot tree, so these are moved over already.
We might want to revisit this.
//Peter
Patrick Georgi wrote:
I'm glad to be able to announce that we moved the repository infrastructure to git and gerrit, with jenkins as supporting facility.
This is exciting!
the coreboot development workflow changes considerably:
- New SCM
You will need git, so install it from your usual software distribution channels.
For Windows users I would recommend installing the command line tools in the msysGit package. During installation there is a somewhat important question about how Git should handle line endings on Windows.
Git can perform automatic translation between line ending formats, so that code in the repository will never use anything but LF line endings, while developers working on Windows will still have every single file in their working tree use CRLF line endings. This translation is enabled by the core.autocrlf setting, which is what the installer will asks for the default value of.
There are many git configuration options. Options can be set either per user (AKA global) or per repository. Options in a repo override the global ones. Options are stored in plain text in ~/.gitconfig or <repodir>/.git/config
You can edit the text files or use the git config command:
git config --global user.name "Peter Stuge" git config --global user.email peter@stuge.se
The above two lines configure git so that all commits I make will have my name and email. It's important that you do the same configuration before you create commits, or they will look really bad and ultimately end up being rejected.
If you run git config inside a repo dir you can leave out --global to change settings locally for that repo only.
If you prefer to use a GUI for Git on Windows then I recommend Git Extensions, which also includes a Visual Studio plugin, so that you can interact with Git a little more easily directly from the IDE if you prefer to use Visual Studio.
But allow me to emphasize that it is highly valuable to learn how to work with Git on the command line. It may feel a little raw, but it is incredibly efficient, and it very much exposes the concepts of Git in a clear way, which I must say I have not really seen in any GUI so far.
For patch submission a gerrit account is necessary. You can register it on http://review.coreboot.org.
Currently registration requires OpenID and might be limited to Google and Yahoo accounts, but I think this will change tomorrow. (I have neither, so I can't register. :) We will certainly work something out.
- New patch submission process
Develop "as usual" in git, and commit freely. When you're ready to submit patches, push them with git push origin HEAD:refs/for/master
HEAD deserves a little discussion.
HEAD is a "meta name" which always refers to the last commit on whatever branch is currently checked out.
Subversion has revisions, Git has commits. Git commits are identified by a SHA-1 checksum calculated from the exact contents of the entire repository. Commit ids can be abbreviated as long as they are unique.
In SVN, revisions are always linear.
In Git, commits can form a directed acyclic graph. ( http://en.wikipedia.org/wiki/Directed_acyclic_graph )
The graph theory is not important, just keep in mind that with Git also the "parent commit" can be significant. So far, all coreboot work has been quite linear, and I think it will continue to be mostly linear, even if Git can handle more complicated situations.
With Git, the branch concept is very important. The actual commits themselves are really low-level building blocks of a Git repository, but it is only common to deal with commit ids while doing e.g. interactive rebase or cherry-picking, which are slightly advanced tasks compared to development using SVN. (But they are really lovely features of Git! More later.)
A Git branch is nothing but a nickname pointing to one particular commit in the repository commit graph. The branch thus also implies a particular commit history; namely all commits that came before the one that is the so-called branch HEAD.
Git is distributed, so *everything* is local by default in Git repos. This goes for commits, branches, tags and everything else. But everything can also be transferred to other repos easily. git push is one way, email is another popular way to at least transfer commits between repositories. Git can send email directly, but thanks to Gerrit it will not likely be used for coreboot. By using git push to transfer stuff over to Gerrit, emails will get sent out without further action from the developer.
So, HEAD in the git push command above refers to the last commit on the checked out branch.
The checked out branch was branched off the master branch at some point in time, and maybe there are new commits in master since then.
Unless there is an actual conflict that's no problem. If there is a conflict, you will eventually have to resolve it. Git may be able to help, but can not always succeed without help, just like svn.
Instead of HEAD you could thus also type the current branch name.
All commits you have done since the branch was created will be submitted to Gerrit, for proposed inclusion in the main coreboot repository master branch.
How and when to create branches is very much a personal thing. I find that I am a little too lazy to create branches as often as would actually be practical, so I sometimes have to do a bit of surgery to move commits around to fix that. :) It is much easier to deal with too many branches, than it is to deal with too few branches.
Note that there is absolutely no requirement to create branches, but it can be really really helpful, so it is a good habit to aquire quickly if you are only just starting to use Git now.
Branches in Git are first class citizens, they are basically nothing more than a name so they are very fast to deal with.
When you clone the coreboot repository, you will get a local Git repository, where you can work completely freely. There are no limitations to what you can do in the local Git repository, so please feel free to work with it any way you like. You can also have multiple repository clones, just like with svn, personally I find this useful sometimes.
After cloning, your local repo only has one branch, called master.
I try to immediately create a branch named according to the particular task or feature to work on next. This is so that the master branch always has only commits that come from the main coreboot repository. ("upstream") Again, I fail at this sometimes and end up doing work on the master branch. I guess this is mostly a matter of choice, how you want to work.
If you want to create a branch, you can do it two ways. The first is:
git branch newcoolfeature
This will create a branch called "newcoolfeature" which points to HEAD. You will stay "on" the current branch. If you make a commit on the current branch (as opposed to on the just-created branch) then "newcoolfeature" does not change and still points to the same commit as before; ie. the second last commit on the current branch.
The other way is:
git checkout -b newcoolfeature [<start_point>]
This does not only create a branch called "newcoolfeature" but it also does a checkout of that branch, so that you will be "on" the branch. If you create a commit after this, then newcoolfeature HEAD will change, and the previous branch will stay unchanged. Sort-of the opposite of what happened above - because even though a new branch was created, "git branch" does not change what the current branch is.
Branches or not, you really only require very few commands after having made a source code change:
git add changedfile.c git commit
Git is more featureful than SVN, so creating a commit is split into two steps. git add will let Git know what you want to include in the commit. You can run git add many times before running git commit. You can even undo. No commit will be created until you run git commit. git add adds the changes you have made in the named files into the "index" AKA "staging area" of the repository. This is a halfway house before the changes are actually committed. It is possible to add only some parts of a changed file, using "interactive add" which is entered by the git add -i command.
Please see git add --help for more information on interactive add.
There exists a shortcut, in case you really truly want to create one commit with every change that you have made in the source tree:
git commit -a
But I recommend to exercise caution with this command. Always using git add is another good habit, because it makes you think a little more about the changes that are about to be committed, which helps create nicely formatted commits, which helps working with commits going forward, which saves time.
Before you create a commit, please review the changes you have made, just like with svn.
The command I like to use for review is git diff. In it's simplest form, git diff will show all changes in your work tree which have not yet been added to the index.
Use git diff --cached to instead show *only* the changes that *are* added to the index; this is what will make up the commit if you would run git commit.
git diff --cached is the perfect way to review changes before creating a commit. git status is also helpful to get an overview of the files that are involved. git status, git diff (with and without --cached and/or other options) and git branch (without parameters) are always safe, read-only, operations that can be run at any point in time, regardless of the repository state, and will provide helpful information about the repo state.
If you push a number of commits at once, they're properly linked as "dependencies", so people (and tools like gerrit and jenkins) are aware about prerequisites.
Pushing a number of commits at once happens when the HEAD that you push has more than one commit that is not available in the branch that your push is targeted at. (Normally the master branch of the main coreboot repo.) So if you have created two commits before you push, then they will be assumed to depend on each other. If the commits are not really related then please keep in mind to push one at a time. Using one branch per related logical change is a good tool to accomplish this.
Praise?
Indeed! Thank you so much for the work getting this infrastructure up and running. I am personally excited to see coreboot start using Git and I think it will actually help developers a lot once everyone has gotten up to speed. For example Marshall and I worked on the last patchset for the E350M1 board exclusively using Git, and it would have taken us a lot more time and would have been a lot more tedious work to accomplish what we did without Git.
I think the same is true for much future development, in particular since we tend to see (and very much prefer!) more patchsets, as opposed to individual patches, and this fits Git very well.
Git is new for several coreboot developers, while some of us have been using it for a while already. If you should run into trouble please get in touch, the very best is to check on IRC, because if there is a problem there will likely be a couple of commands back and forth before the problem has been resolved, and email can be somewhat slow and impractical.
Kind regards
//Peter
Patrick Georgi wrote:
I would also like to recommend http://progit.org/ which in spite of it's name is quite suitable also for those who are just starting to use Git.
//Peter
Hi Patrick
On Sun, Jun 5, 2011 at 4:48 PM, Patrick Georgi patrick@georgi-clan.de wrote:
Dear coreboot developers, stakeholders, and enthusiasts,
I'm glad to be able to announce that we moved the repository infrastructure to git and gerrit, with jenkins as supporting facility.
That sounds great, very good job. Could you move buildrom to gerrit as well?
Regards,
Am Montag, den 06.06.2011, 07:25 -0400 schrieb Leandro Dorileo:
That sounds great, very good job. Could you move buildrom to gerrit as well?
I'd wait and see until the dust settled over coreboot before considering any more migrations.
Patrick
Hi Patrick,
On Mon, Jun 6, 2011 at 7:32 AM, Patrick Georgi patrick@georgi-clan.de wrote:
Am Montag, den 06.06.2011, 07:25 -0400 schrieb Leandro Dorileo:
That sounds great, very good job. Could you move buildrom to gerrit as well?
I'd wait and see until the dust settled over coreboot before considering any more migrations.
Yeah, seems wise.
Thanks,
On Sun, Jun 5, 2011 at 1:48 PM, Patrick Georgi patrick@georgi-clan.dewrote:
- Mail notification
Mail notification to the mailing list is implemented from scratch. Right now it only reports on new patch submissions and on patches merged into the master branch. More events might/will follow in future, and we will certainly tweak the ad-hoc messages and formatting some more.
I suggest squelching the "Patch set updated" messages on the mailing list. Reviewers will get the notifications anyway, so for those who are not reviewing a patch those notifications are excessive.
Patrick Georgi patrick@georgi-clan.de writes:
Dear coreboot developers, stakeholders, and enthusiasts,
I'm glad to be able to announce that we moved the repository infrastructure to git and gerrit, with jenkins as supporting facility.
Yay! Go Git.
Question, though: is this going to be accompanied by a revised tagging/versioning scheme? I realize Coreboot has a history of simply using SVN revisions as version indicators, but I personally must admit I always found that a bit fast and loose. However, at least the revision numbers were sequential, and carried _some_ meaning. You could for instance tell at a glance roughly how old any given version was, how much you (or the version subject to an error report) was trailing HEAD.
Additionally, I suspect hashes are a bad way of communicating version information to more casual users ("what is the latest stable/tested version?", "what version should I use for my foo bar mainboard?").
Lastly, and more pragmatically, I need something to put into the version drop-down at http://lxr.linux.no/coreboot. This is of course the motivation for this email. :) I'm not really keen on git hashes, but the more active members of the project obviously need to determine what works for Coreboot as a project.
-
Arne Georg Gleditsch -
David Hendricks -
Gregg Levine -
Leandro Dorileo -
Patrick Georgi -
Paul Menzel -
Peter Lemenkov -
Peter Stuge -
Thomas Gstädtner