Now that you know more or less how things in git work, it’s time to set up your repositories to contribute with gnome. First thing you want to do is to get the latest source code, but jhbuild does that for you (see
https://wiki.gnome.org/GnomeLove/JhbuildIntroduction). Acutally, for me, jhbuild was getting the latest stable branch (i.e. gnome-3.12 at the moment) and not master, which is the most recent development branch. In order to force jhbuild to get the master branch for evince (which is the project I am working on) I had to add this line to my jhbuildrc:
branches[‘evince’] = ‘master’
So jhbuild downloaded the source to the ‘checkoutroot‘ set in jhbuildrc. You can go there and type ‘git status‘ to see that it is a git repository. After building, I get this:
# On branch master
# Untracked files:
# (use “git add …” to include in what will be committed)
#
# test-driver
nothing added to commit but untracked files present (use “git add” to track)
Don’t worry about this untracked file. It’s always there (at least for me!).
If you are very brave, you can start making changes right there and then, but it is probably better to create a branch on which you can test and develop stuff without messing up the stable code. To see the existing branches, just type
‘git branch‘ or ‘git branch -v‘.
The -v option will inform you what was the latest commit on each branch. I think it’s useful. You will probably see only one branch, called ‘master’ marked with a *. The * is there to show you that this is the branch you’re at. Go ahead and create another branch with
‘git branch dev‘.
You can replace ‘dev’ with a better name. In my case it is called annotations, since this is evince’s feature I will work on. Check the branches again. See the new one? You can change to this branch using:
‘git checkout dev‘.
So far so good. Let’s say you change something there, and it’s ready to be committed:
‘git commit -a‘.
The -a option will include all the changes to all the previously existing files. Make sure that the code still compiles and runs with the new commit! Check the log:
‘git log‘.
See the commit there? So everything is good. Now what? Well, I doubt you will have permission to push this directly to gnome’s git. Someone needs to revise the changes you made and, at least for the first few changes, you will receive a lot of feedback. But how can they revise your changes if your commit is local? If you are fixing a bug, you can create a patch from your commit and attach it there. For creating a patch from one commit, you need to run:
‘git format-patch -1 sha‘.
Where “sha” is a big string with numbers and letters that appears right after the word ‘commit’ when you see the log. Now, if you are a gsoc student like me, you wouldn’t like to flood your mentor with patches every time you make a change. My solution was to create a github account and push my commits there. So every time my mentor wants to check what’s new, he can take a look there. (Here goes a big thank you to jaliste, my mentor, and gpoo, my sub-mentor, for helping me organize this!!)
Github has instructions on how to set up a repository (https://help.github.com/articles/create-a-repo). You can follow this until step 1. Don’t create the readme file, you already have files. Instead, go straight to step 3. What you need to do is add the github rep as a remote repository, in parallel with gnome’s git. If you go to the directory where your project is and type
‘git remote -v‘
you will see that you have one remote entry, called origin, that points to gnome’s git. Now create another entry:
‘git remote add github https://github.com/username/yourprojectname.git‘
If you list your remotes again you will see origin and github. Now let’s push the stuff to github! First, go to the master branch (‘git checkout master‘). You will push whatever is there (i.e. the official gnome commits) to your github:
‘git push github master‘.
If you go to github’s website, you will see all of gnome’s commits listed on the master branch of your project. I am keeping my local master branch as a bridge between gnome’s master and github’s master. They are always in sync. To do that, I pull the changes from gnome and push them to github:
‘git pull origin master‘
‘git push github master‘
Make sure you are on your local master branch when you do this, and that you did not accidentally commit anything there. You’re almost set. Next step is to send your dev branch commits to github. Again, change to dev (‘git checkout dev‘), and push:
‘git push github development‘
Note that github’s branch name is not necessarily the same as yours. Also, if ‘development’ does not exist on github, this command creates it for you! Practical, right? You can go there on github’s website to check if it’s all ok!
Remember you can create as many branches as you want, depending on the tasks you are working on. Just make sure you are on the correct branch for changing and committing the code. After a lot of fighting with git and github and gnome, I found that this is a nice way to keep things. I hope it is also easy for others to track and review my changes 🙂