Contributing to X2Go

Before you start contributing make sure git git knows who you are, as this is added to the patches.

Setup Git Configuration

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):

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:

TODO: Write/Link howto

patches@x2go.org

Developer Git Access via SSH

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).

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.

Now you can start working on your new X2go project as on any of the other already existing X2go Git projects.

Edit Git Configs

As x2go-admin on code.x2go.org:

$ cd /srv/git/code.x2go.org/<x2go-project>.git
$ vim config

Edit Git Descriptions

As x2go-admin on code.x2go.org:

$ cd /srv/git/code.x2go.org/<x2go-project>.git
$ vim description

Edit Git ACLs

Unused feature, may come later…

Backyard

Is this really needed??!

Reverting Merge Commits

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:

change a file

commit it locally

push it to X2go Git

find that the push operation gets rejected

then run git-pull instead

and then uuups… realize: the git-pull fetched in some code for the same file, I have just been working on…) → you probably forgot to run a git-pull before 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

Pushing to X2go Git

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

When working on master's HEAD do not wait too long before pushing them to the server as it may happen that others work on master's HEAD as well.

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

whitespaces found at the end of lines

tabs found in the file (for Python: no tabs, for Bash, Perl, C++, etc. tabs are wanted, so you can ignore these if not coding Python)

no \newline at end of file

You may consider silencing those warnings before committing the next time…