The main git server. Should be used only for pushing new commits to a repository over the SSH protocol.
Several servers which allow read-only access to the repositories via the git:// and http:// protocols. They are requested to update when anyone pushes to a repo on git.kde.org, so it can be thought of as being always up-to-date.
KDE developer accounts are managed through KDE Identity. If you already have a KDE SVN developer account, it has been imported into KDE Identity and you may use the Password Reset feature to set a password and manage your SSH public keys. If you don't have a developer account yet, you can request Developer Access in the website's menu upon registering and logging into your account.
Anonymous read-only access uses the following URL prefix:
Read-write developer access uses this prefix instead:
Following the prefix, here are the path schemes for different types of repositories:
Instead of remembering the above URL prefixes, you can also put the following in your ~/.gitconfig:
[url "git://anongit.kde.org/"] insteadOf = kde: [url "firstname.lastname@example.org:"] pushInsteadOf = kde:
Then, to clone e. g. the Amarok repo, just do
$ git clone kde:amarok
By using the kde: prefix, read access will automatically happen over Git, and authenticated SSH is only required for pushes.
git.kde.org understands several server-side commands that can be used on the command line via SSH in this fashion:
ssh email@example.com <command> [parameters]
The following is a list of the commands that are currently available, broadly divided into categories according to their purpose.
ssh firstname.lastname@example.org clone konversation mykonvi
ssh email@example.com clone websites/projects-kde-org newtheme
ssh firstname.lastname@example.org hooks-enable konversation
git.kde.org currently offers two types of personal repositories: Personal clones of project repositories and personal scratch repositories.
A personal clone of a project repository can be created using the server-side clone command on the command line:
ssh email@example.com clone <path to source repository> <clone name>
This will create a clone of the source repository at clones/<path to source repository>/<KDE Identity user name>/<clone name>. (See more examples of clone in action here.)
This scheme makes it very easy to locate all personal clones of a given project and should be preferred over making one in your personal scratch space. (In fact, the server-side clone command won't allow you to clone a project repository into your personal scratch space, but nothing technically prevents you from taking the detour of a local clone to achieve this.)
Personal scratch repositories are a means to start a new project or just to store your favorite .bashrc in a safe location: anything is allowed so long as it is related to KDE or your work for KDE in some way.
Creating one is easily done by just pushing:
git push --all firstname.lastname@example.org:scratch/<your KDE Identity user name>/<repo name of your choosing>
(Or you could use git remote add to add a remote to push to.)
Personal scratch repositories can be browsed on gitweb.kde.org.
If you feel your new project is ready for the wider world and/or wish to signal that it welcomes outside contributors, you may wish to promote it to the status of a KDE Playground project. KDE Playground project repositories are located at the top-level, i.e. the repository will be moved out of your scratch space and may have to be renamed in the event of a collision with an existing repository name. KDE Playground projects are featured on KDE Projects and covered by the kde-commits mailing list (and thus CommitFilter), LXR, the EBN and CIA, unlike personal scratch repositories.
To request your scratch repository be promoted to the status of a KDE Playground project, you currently need to file a sysadmin repo request. In the future we plan to provide a fully automated facility on KDE Projects.
Note that we have deliberately decided not to allow the direct creation of KDE Playground projects; the path to existence for a KDE Playground repository project always leads through a personal scratch space first. This is to give you the power to decide whether your project is ready, and also to force you to deliberate whether it truly is.
A personal repository can either be deleted outright and irrevocably by using the destroy command (which requires you to unlock it first to avoid accidental deletion), or you may move it to the personal trash area with the trash command.
Entries in the personal trash area are kept for 28 days, and can be resurrected at any moment during those 28 days by way of the restore command. You can list the current contents of your personal trash area with the list-trash command.
A very comfortable way of posting changes for review is ReviewBoard, where every project repository has its own entry.
To create your changeset, you probably want to work in a separate branch - or even in your clone. This is actually suggested and the proper way to do changesets in Git. You can create any number of commits, amend them, and do whatever you want to do - it won't affect the next steps, as you will submit the whole branch for review.
Before proceeding it is good practice to rebase your branch onto the branch you want to target for the merge. So, supposing you want to target master, make sure it is up-to-date with the remote and then run, and want to publish a review for a local branch:
git rebase master
If you want to post a review for merging a non local branch, you might want to run the following:
git merge master
Once you are done with the above, it is time to post the changes to ReviewBoard. The easiest and most comfortable way to do that is post-review, a handy command line tool which takes care of creating review requests for you.
The following has to be done only once to make your local clone fit for use with post-review.
First of all, you have to tell it about the ReviewBoard server. If your project does not ship with a .reviewboardrc file (encourage the project manager to add one!), the first thing you have to run is:
git config reviewboard.url http://git.reviewboard.kde.org
ReviewBoard currently only knows the project repositories by their git:// URLs, making it necessary to have a remote using the git:// URL in your clone. If your origin remote is already using the git:// URL, you are all set. If not you need to add another remote now.
Let's suppose you are looking to have some changes to Amarok reviewed, and the URL of your origin remote is email@example.com:amarok. To add another remote using the git:// URL you might run:
git remote add anonupstream git://anongit.kde.org/amarok git fetch anonupstream
If your origin remote was already using the git:// url, substitute anonupstream with origin throughout the rest of this tutorial.
You are now ready to create the review request. The post-review command should look something like this:
post-review --parent=master --tracking-branch=anonupstream/master
This command tells post-review that your branch is based upon master, and it is set to track the remote branch anonupstream/master. You can also give post-review some more arguments to avoid using the web interface later - have a look at the user manual for more on that.
After the command has been run a web address will be shown in the terminal, pointing at your review request.
If you need to update an existing review request you can invoke post-review with an additional -r argument, which should be the numeric id of the review request you want to update. Supposing you want to update review request 54, you would run:
post-review --parent=master --tracking-branch=anonupstream/master -r 54
In some rare cases you simply want to generate a diff and submit it to ReviewBoard later. You can do that by running:
post-review --parent=master -n > your-patch.patch
To close a review request, you can either use the ReviewBoard web interface or more conveniently, right in a commit. This is done by using the REVIEW keyword followed by the review ID you want to close. For example, to close review 54, you would put
in your commit. A message will also be posted to ReviewBoard indicating the commit SHA1 that closed the request.
To get your project moved from KDE SVN or Gitorious.org to git.kde.org, you have to file a sysadmin request. The form is still in development, but should work fine. It will ask you for the following information:
When we have completed processing your request, there will be an empty repository at the chosen path (more here) that the repository administrators can push the data into. (When converting from KDE svn to git this typically involves writing a rule set, running svn-all-fast-export, and then pushing the created repository into the new git path.) Once you are done pushing everything to the repository, use the hooks-enable command to enable the commit hooks and allow write access to non-administrators.