Xfce Wiki

Sub domains

This is an old revision of the document!

Xfce.org Git Infrastructure

All Xfce SVN repos have been converted to git.

Account Setup

If you have an xfce.org Subversion account that does not include ssh access (that is, you check in using https), you will need to apply to get your account converted here. Fill out the form with the same info you used previously, but remember to include a ssh public key in the appropriate box. Translators: see here.

If you used the “old” git.xfce.org, and used clone/push URLs like “git@git.xfce.org:$USER/$MODULE”, then you should follow the directions above as well.

You will receive an email with instructions when your account is ready.

If you already have a ssh shell account on git.xfce.org (aka mocha.xfce.org), your account information has not been changed and you are ready to go.

If you do not have an xfce.org account at all, you'll need to request one using the usual process.


If you are uncertain of the clone URL to use for a particular module, please find and click on the module in the listing in CGit. Clone URLs are listed at the bottom of the page for each module.

To pull from $MODULE in $TYPE you'd use this command (where TYPE is 'apps', 'bindings', 'xfce', etc):

git clone ssh://$USERNAME@git.xfce.org/git/$TYPE/$MODULE

This will automatically set up the 'origin' remote in the cloned repository to point to that location, so a “git push” will do the right thing. If your local username is the same as your git.xfce.org ssh username, you can omit the $USERNAME@ portion of the URL.

Unfortunately, we cannot support https pushes at this time due to limitations in the Git http protocol support.

Read-only clones can be obtained via:

git clone git://git.xfce.org/$TYPE/$MODULE


git clone http://git.xfce.org/git/$TYPE/$MODULE

Viewing of the repository in a web browser is provided by a CGit instance at http://git.xfce.org/.

Translator Access

Translators will be using our Transifex install to submit translation updates. Direct access to the git repository will no longer be provided. NOTE: This is not set up yet. Existing translators will receive an email when their Transifex account is ready.

Account Maintenance

To change or set your password, run:

ssh -t $USERNAME@git.xfce.org passwd

(The -t option makes it so your password won't get echoed to the terminal as you type it; if you don't care, feel free to leave it out.)

To list your active ssh keys, run:

ssh $USERNAME@git.xfce.org ssh-key-admin list-keys

To add a ssh key, run:

ssh $USERNAME@git.xfce.org ssh-key-admin add-key "ssh-rsa kjlsdkf... me@example.com"

Be sure to remember the quotes around the key data itself. Paste the entire contents of your .pub file (usually $HOME/.ssh/id_rsa.pub or $HOME/.ssh/id_dsa.pub).

To remove a ssh key, run:

ssh $USERNAME@git.xfce.org ssh-key-admin del-key me@example.com

You'll need to use the “key comment” when removing keys, which is the last section of the key data in the key file (everything from the last space to the end of the line). You can use the list-keys command above to get a list.

New Repositories

For 'Goodies' developers, we used to have an “open repository creation” policy in our Subversion repo in which any user with write access could create a new module for a new project. With the move to Git, this is no longer possible. You will need to request the creation of a new Git repo by emailing xfce-repo-admin@xfce.org to request a new module. Please include the module name, which category it should be under (apps, art, bindings, libs, panel-plugins, or thunar-plugins), a description of the module, and a rationale as to why it should be hosted on git.xfce.org (instead of github, gitorious, etc.). Note that requests to be added to the 'admin,' 'archive,' or 'xfce' categories will be denied.


  1. Modification of tags is not allowed after they have been pushed to the main repository.
  2. Pushing “lightweight” non-annotated tags is not permitted.
  3. Pushes that result in a non-fast forward update for 'master' branches, and 'xfce-4.x' branches are not allowed.

Repository Identification

In order to display repository metadata on the CGit listings and other places, modules will need a file called “module.xml” in the root of their tree (on their master branch). This file should be a DOAP file describing the project. You can work off this template.

Please at least provide <foaf:name>, <foaf:mbox>, and <gnome:userid> elements (the latter of which should be your Xfce ssh account username). You can of course provide more information about yourself if you'd like; see foaf:Person and foaf:Agent.

For now, only include one <maintainer> element block. If there are other active developers (or former developers you wish to credit), use a <developer> element block for each one.

Note that the file in your git repository should actually be named “module.xml”. Do NOT replace “module” with the actual name of your module.

Changes will not show up immediately; the listings are only regenerated twice daily.

Commit Notifications

We are doing away with the goodies-commits email list. All commit mails in all git repositories will go to the xfce4-commits list. The subject lines of the emails should be pretty easy to filter on if you only want a subset of emails. We generate one commit mail per commit object (and for some other things too), so if you push a large number of commits, you'll generate a large number of emails.

Tips and Tricks

  • If you clone a lot of Xfce repositories, you can set a shortcut so you don't have to type out the full URL all the time. Simply run:
git config --global 'url.ssh://git.xfce.org/git/.insteadOf' xfce:

After this, you'll be able to do, for example:

git clone xfce:xfce/xfdesktop

and Git will automatically rewrite it to the correct URL. You can of course do this with git: and http: URLs as well.

  • If your ssh username is not the same as your local username, you can make an entry in $HOME/.ssh/config (create it if it doesn't exist) so you don't have to type it each time:
Host git.xfce.org
    User $USERNAME

Of course, replace $USERNAME with your actual username.

Migrating From git-svn Clones

This section is only useful for developers who were using git-svn to access our old Subversion repositories.

If you have a git-svn clone and there are commits in it that you never pushed to svn, and want to merge them into a new git clone, it can be a little bit of a pain. Because of how the repositories were converted, the git-svn clones do not have the same SHA1 sums for any old commits (that is, commits that were pushed to the svn repo). So you can't just import a branch directly and expect it to work.

The following is what I (Brian) did. It's really manual and annoying. If anyone has a better way, feel free to edit this and describe your method.

Here I'll use my xfdesktop repo as an example. I'll refer to the new git clone simply as xfdesktop, and the git-svn clone as xfdesktop.git-svn. I want to merge the branch new-drawing from xfdesktop.git-svn over to xfdesktop. Here's what I'd do:

$ cd xfdesktop
$ git checkout master
$ git checkout -b new-drawing
$ git pull ../xfdesktop.git-svn new-drawing:refs/heads/tmpbranch
$ git reset --hard new-drawing
$ git log tmpbranch

At this point, I'll look at the log output and figure out which commits were never pushed to the main Subversion repository. It's easy to tell because those commits don't have git-svn-id: lines at the end of each commit message.

Now, I make a list of the SHA1 hashes of the commits I need to migrate. I'll order them in the reverse order, so that the first commit to migrate will be the oldest out of my list. In my case, I only have two commits, so my list (after reordering) looks like this:


At this point I could make a script to cherry pick them all in order, but since I only have two I'll just do it manually:

$ git cherry-pick d1e0179e8b6f00e4f452513c100f674f7d35dc11
$ git cherry-pick e3633d52774bd9a2a20ef9af37d3f72f964a2f54

Now, if I got any merge errors after one of the cherry pick commands, I'd have to stop there and fix it up first:

$ vim src/xfdesktop-icon-view.c
[fix the merge conflict and save]
$ git add src/xfdesktop-icon-view.c

The merge conflict error message provided a useful bit of info: after fixing the conflicts, you can easily re-commit using the same log message, author, and author date as before by using the -c option to git commit:

$ git commit -c e3633d52

Note that the argument to -c is just a shortened form of the SHA1 hash for the commit that caused conflicts.

Now that we're done, we can delete the temporary branch:

$ git branch -D tmpbranch

You'll have to repeat this process for any other local branch you have in the old git-svn clone. As I said, yes, it's annoying, repetitive, manual, and time-consuming (if you have a lot of branches/clones to convert). If anyone knows a better way, feel free to detail it here.