-
-
Notifications
You must be signed in to change notification settings - Fork 2
Tips and Tricks
It is possible to upload changes to a personal sandbox on Gerrit. This way a change can be shared between machines and developers before it is ready for code review.
To upload a change to the personal sandbox:
$ git push origin HEAD:refs/sandbox/mygerritusername/branchname
To list available sandboxes in project for user mygerritusername:
$ git ls-remote git://gerrit.lsdev.sil.org/project.git 'refs/sandbox/mygerritusername/*'
To delete a branch in the personal sandbox:
$ git push origin :refs/sandbox/mygerritusername/branchname
To fetch a branch from the personal sandbox of user mygerritusername in project:
$ git fetch git://gerrit.lsdev.sil.org/project.git refs/sandbox/mygerritusername/branch && git checkout FETCH_HEAD
If you want to create a local branch from the fetched sandbox:
$ git checkout -b branch FETCH_HEAD
NOTE: You can fetch sandboxes from other users, but you can push only to your own sandbox!
The fwmeta repo contains a script gethistory which allows to get the older history of the repos (contained in the *-antique.git repos). The script asks for the names of the repos and branches for which it should get the older history and then downloads the commits from Gerrit and ties them into the current history. Afterwards a git log shows the history back to the beginning.
Since downloading from Gerrit is pretty slow, gethistory can take an additional parameter --alternate-url that allows to specify the location of local copies of the *-antique.git repos. Those can be on the local hard drive, a shared network drive, or on a CD/DVD. However, the script expects to find a complete repo, i.e. a FieldWorks.git repo that had the gethistory script run before isn't sufficient, instead it expects to find the FieldWorks-antique.git repo.
If you call gethistory with parameter --help it'll show the possible parameters and an example.
When a change is ready to be submitted often times you have to rebase the change and then wait some more time until Jenkins built with the rebased change. Depending on how many people try to submit another change might have been submitted in the meantime, requiring another rebase.
You can add "autosubmit" as reviewer in Gerrit. This causes the change to be rebased and submitted automatically when it's reviewed and verified. If the rebase fails because of conflicts the change author gets an email.
Occassionally some tests fail for no apparent reason - they'll probably pass when build again. However, since the builds on Jenkins are triggered by a new patchset it's not possible to simply click the "Build Now" link since the build needs some information from Gerrit.
Instead, go on the build status page of the failing build (e.g. .../Gerrit-FieldWorks-Linux-any-develop-debug/1072/) on internal Jenkins. There you'll find "Retrigger" and "Retrigger All" links. The former rebuilds just on the current platform, the other on both Windows and Linux.
Another option is to use the "Query and Trigger Gerrit Patches" link on the main page of internal Jenkins. This allows to query for changes, e.g. status:open project:FieldWorks and triggering specific patchsets.
When you upload a merge commit for review you might have to rebase it because someone else checked in a change in the meantime. Instead of aborting the change and starting over, you can run
git rebase --preserve-merges <whatever>