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.
You can find general information about using Git as a KDE Developer on the KDE Git page on TechBase.
To configure Git for your KDE Development environment, please see the KDE Git Configuration page on TechBase.
You can find some simple step-by-step recipes for using the KDE Git repositories on the KDE Git Recipes page on TechBase.
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:
If you are in a corporate environment (e.g. behind a firewall) which only allows Ports 80 (HTTP) and 443 (HTTPS), use the following configuration instead (i.e. substitute git:// for http://):
[url "http://anongit.kde.org/"] insteadOf = 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. Since commits are mirrored to anongit right when you push them, you will not have to worry about anongit being outdated.
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]
To simplify the first argument to "kde" (i.e. "ssh kde <command> [parameters]"), put the following in ~/.ssh/config:
Host kde HostName git.kde.org User git
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 clones of project repositories currently do not show up on KDE Projects, but we have plans to change that in the future. Until then, you can use quickgit.kde.org to browse these repositories.
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.
For the rest of this instruction, let's assume the following names:
If you start a new project then you need to create a git repository out of it before you start to push it to the scratch repositories. This is done by going into the the directory which will contain your project and type:
This will convert the local directory to a git repository. This is of course not necessary if you already have a local git repo containing your project.
To make pushing to the repository convenient, it is recommended to add a remote to push to first:
git remote add origin firstname.lastname@example.org:scratch/<kde-id>/<repo>
Now you need to create something to push. Otherwise git will refuse the next step. So it is recommended that you create a README for your project and then commit that. Afterward, you perform the first push to the repository as follows:
git push --all origin
Now your new scratch repository is created and initialized. It will take about 30 minutes until the creation of the new repository has propagated to the other tools and is visible there.
git push --all does not push tags. You can push them in a second step with
git push --tags ...as above...
Personal scratch repositories can be browsed on quickgit.kde.org.
You can set a description on your scratch repository by issuing a command
ssh email@example.com desc scratch/<kde-id>/<repo> "Application to do magic"
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, and EBN, 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 rm 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.
ssh firstname.lastname@example.org D trash scratch/<username>/<project>
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 Review Board, where every project repository has its own entry. You can read about how to use Git and Review Board on the KDE Review Board page.
Here's an insightful blog post that explains how to use post-review.
To get your project moved from KDE SVN or Gitorious.org to git.kde.org, you have to file a sysadmin request. 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.
With these techniques, always work on a disposable copy of the repo with all the remotes removed, so if you screw up, it doesn't really matter. Also, work on a separate branch. That way, you can usually use git reset --hard <original-branch> to get back to the starting state.
Also, make sure there are no grafts around (eg: linking to the old kdelibs history in the case of frameworks). The safest way to do this is to use fresh checkouts.
The git-merge-repo script in kde-dev-scripts can merge the tree and history of one git repository into another.
First, create a commit in the source repo that removes any files you don't want to copy, and rearrange the remaining files to be as you want them to appear in the target repo. It is important the HEAD of the source and target repositories have completely disjoint trees (so you could copy one tree into the other with no file conflicts).
Then go to the root of the target repository and run
/path/to/kde-dev-scripts/git-merge-repo <path to source repo>
This will preserve commit identities (unless you filter the source repository - see below).
git filter-branch allows you to edit history. This is useful when you want to merge only a small part of one repository into another. You can trim the tree, and also alter the commit messages (for example to add information about the origin of the commits).
A combination of --tree-filter, --prune-empty and --msg-filter generally gets what you want. For example,
git filter-branch --prune-empty \ --tree-filter "find -type f -\! -path './.git/*' -\! -name foo.\* -delete" \ --msg-filter 'cat; echo; echo "Commit $GIT_COMMIT in <source-repo>"' \ HEAD
This example will remove everything that does not match foo.*. Note the -path argument to find that makes sure you don't delete any of git's own files. --prune-empty will remove non-merge commits that no longer have any effect on the tree (you can run git rebase after to trim the merge commits if you want). --msg-filter adds information about where the commit came from (don't forget to change <source-repo>!)
More complex filters are possible. Have a look at the man page for git-filter-branch. Note that while you could use the commit message filter to neuter commit hook keywords like CCMAIL, it is better to ask a sysadmin to disable the commit hooks temporarily while you push.
See mastering git filter-branch: points to extract a subproject for more helpful hints.