This is an old revision of the document!
Within the X2Go project development code is shared via a public GIT repository hosted by DAS-NETZWERKTEAM in Kiel, Nothern Germany (Servers: Hetzner Online AG). For any technical X2Go GIT related questions, please contact our GIT repository administrator (currently: Mike Gabriel):
git-admin (at) x2go (dot) org, a discussion about content should be held on the developers' mailing list:
The Web service is also available as a https service. To make secure browsing as smooth as possible, please import this Root-CA-Certificate into your web browser: http://das-netzwerkteam.de/NWT-ca.crt
X2Go's Git projects can be cloned to a local copy through anonymous Git with the following instruction set (in a Unix-like console session).
$ mkdir -p ~/x2go $ cd ~/x2go $ git clone git://code.x2go.org/<package>
For <package> names please refer to the Git WebGUI (see above).
Before you start contributing make sure git git knows who you are, as this is added to the patches.
Now it is time to set up your system environment for working with Git. Main thing is to tell Git who you are. For this edit the file
~/.gitconfig with your favourite editor and put the followings lines in it (of course, you may want to personalize some of the fields):
[user] name = <Firstname Lastname> email = <firstname.lastname@example.org>
Only project developers can access X2Go's Git tree via the SSH method. Please understand that we only restrictively grant write access to our GIT repository. However, you can send us patches via Mail (git-send-email). For submitting X2Go patches, please use this eMail address:
In the instruction set below, substitute <package> with the X2Go source package that you want to work on, substitute <branch> with the name of the branch of <package> you are contributing to. The SSH <port> to use for Git write access will be provided to developers only and will not be named in this Wiki. Access via SSH will only be granted by SSH public key authentication (no password auth).
$ cd ~/x2go/<package> $ git push ssh://email@example.com:<port>/srv/git/code.x2go.org/<package> <branch>
RSA Key: ab:cd:4b:b2:d1:d1:19:11:ed:24:83:5a:06:b1:d4:d3
Commits and tags in X2Go Git are posted as e-Mails to two different mailing lists:
These mailing lists can be subscribed to by anyone who is interested in X2Go Git changes. However, beware that there might be phases you get flooded by mails, if you subscribe to any of these lists (esp. x2go-commits). Furthermore the lists are read-only. Postings to these lists will be dropped automatically by the mailing list service.
Both mailing lists are also archived at Gmane:
This is for bash
for REP in \ buildscripts.git \ cups-x2go.git \ libjpeg-turbo.git \ libpam-x2go.git \ lightdm-remote-session-x2go.git \ ltsp-pyhocathinclient.git \ nx-libs.git \ pinentry-x2go.git \ pyhoca-cli.git \ pyhoca-contrib.git \ pyhoca-gui.git \ python-paramiko.git \ python-x2go.git \ x2go-keyring.git \ x2goadmincenter.git \ x2gobroker.git \ x2goclient-contrib.git \ x2goclient.git \ x2goclient2.git \ x2godesktop-applet.git \ x2godesktopsharing.git \ x2gognomebindings.git \ x2golxdebindings.git \ x2goplasmabindings.git \ x2goserver.git \ x2gothinclient.git \ x2gotrinitybindings.git \ z99.ubuntu/libev.git \ z99.ubuntu/python-crypto.git \ z99.ubuntu/python-gevent.git \ z99.ubuntu/python-greenlet.git \ z99.ubuntu/python-pampy.git \ z99.ubuntu/python-setproctitle.git \ ; do git clone git://code.x2go.org/$REP; done
Create a local Git project:
$ mkdir -p ~/MyCode/x2go-upstream/x2gonewthing $ cd ~/MyCode/x2go-upstream/x2gonewthing $ git init
Then add your first files to the new
x2gonewthing project. Commit these files as the first commit. Maybe commit more…
Then run the following command sequence:
$ cd ~/MyCode/x2go-upstream/ $ x2go-gitcreate x2gonewthing # if the Git creation succeeds (check via http://code.x2go.org/gitweb), only then... $ rm x2gonewthing -Rfv $ git clone ssh://firstname.lastname@example.org:32032/srv/git/code.x2go.org/x2gonewthing.git
Now you can start working on your new X2go project as on any of the other already existing X2go Git projects.
$ cd /srv/git/code.x2go.org/<x2go-project>.git $ vim config
$ cd /srv/git/code.x2go.org/<x2go-project>.git $ vim description
Unused feature, may come later…
If you forget to run
git-pull before modifying code files you will run into merge problems when committing your changes.
There is nothing bad about merge commits apart from the fact that the X2go Git system won't allow them being pushed to the server .
Thus, you probably want to avoid merge commits right from the beginning. However, from time to time it occurs that you crunch your Git log with a merge commit. This is how such a thing can happen:
git-pullfetched in some code for the same file, I have just been working on…) → you probably forgot to run a
git-pullbefore starting to work on that particular file…
One possible solution for this is cherry-picking. Here is an example (presuming that your are working on the master branch):
# make a temporary backup copy of the master branch $ git checkout -b master-bak-tmp # go back to master branch $ git checkout master # and reset it to that refspec where local Git and server's Git were known to be still in sync $ git reset --hard <last-refspec-known-to-be-identical-with-server> # then take a look at the log of your old local master branch $ git log master-bak-tmp # now cherry-pick your local changes individually from the master-bak-tmp branch (where refspec-1 ... refspec-n are the commit hashes of each commit): $ git cherry-pick <refspec-1> $ git cherry-pick <refspec-2> ... $ git cherry-pick <refspec-n> # finally drop the tmp backup of old master $ git branch -D master-bak-tmp
Whenever your local X2go Git project is in an acceptable state for the community, feel free to push the code to the X2go Git server:
$ git push
Keeping back code for too long can result in code conflicts (changes in the same code block of the same file by two different developers).
The update scripts of X2go Git will shout warnings at you while pushing. These warnings relate to
You may consider silencing those warnings before committing the next time…