Pull Request and Code Review in GitHub's Shared Repository Model

Many people do not realize that you do not have to fork a repo in order to do pull requests and code review. In GitHub's shared repo model where a team of people have equal access to a single repo, pull requests and code review can be done between two branches of the repo. The basic workflow is creating a new branch, making pull requests from this new branch to master, and after your changes are accepted, merging them into master and deleting this temporary branch. David Winterbottom wrote a post about this workflow at http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github. I added some of my understandings, and simplified this workflow according to my common use-cases:

1. Creating a new branch: Say the new branch is called "feature". git checkout -b feature. 
2. Make your changes. 
3. Commit your changes using "git commit". You can commit multiple times. It does not quite matter, because these changes are on this separate branch. You can later merge them into master however you want. 
4. Push your changes: git push origin feature. 
5. Go to the project's GitHub page, and issue a pull request. Make sure you pick "master" as the base branch, and "feature" as the head branch. 
6. Wait for your changes to be accepted. If you are asked to revise your changes, go ahead editing your branch and pushing your new changes. GitHub will automatically update the pull request to contain your new changes, so you do not need to issue another pull request. Note that when you commit your new changes, you should not use "git commit --amend" because your old commit is already pushed. Also, do not worry about multiple commits in your branch, because you can later squash them when merging them into the master branch. 
7. Clean up your history: git rebase master. This command rebases your changes on top of master, so that the later merge to the master branch can be fast-forwarded. If you did not sync the branch branch after branching (step 1), this command likely does nothing and simply shows the current branch is up-to-date. 
8. Merge your branch into master. First, switch to the master branch using "git checkout master". Second, "git merge feature" or "git merge --squash feature". The latter command squashes all the commits into one commit, which is recommended because these commits most likely achieve the same goal. If you go with "git merge --squash feature", you need an extra "git commit" and modifying the commit message. 
9. Push your changes to the master branch: git push. You may need to "git pull --rebase" and resolve some conflicts if your local master branch is older than the remote one. 
10. Delete the branch you created: Now that you have pushed your changes to master, you can happily remove the branch you created. First, delete it from your local repo using "git branch -D feature". Second, push the deletion to the remote repo using "git push origin :feature". 

Let Ubuntu gnome-terminal Support 256 Colors

The gnome-terminal in later versions of Ubuntu already supports 256 colors, however it still reports its term type as "xterm" indicating it supports only 8 colors. This over-conservative report creates small issues for some applications such as "tmux", because "tmux" decides the number of supported colors based on environment variable "TERM".

Most instructions online tell you to add an extra line "export TERM=xterm-256color" in your .bashrc file in order to support 256 colors. However, this extra line sometimes creates problems because environment variable "TERM" should be reported by the terminal instead of the shell. For instance, "tmux" usually sets TERM to be "screen-256color" in order to better support special keys such as "Home" and "End". However, the extra line "export TERM=xterm-256color" would overwrite tmux's terminal type and create annoying issues such as the home key not working. Therefore, what I would suggest is to set the terminal type in the command of your gnome-terminal (Profile Preferences => Title and Command => Run a custom command instead of my shell). For example, if you are using bash, set the command to be "env TERM=xterm-256color /bin/bash".

There are several ways to check whether your terminal colors are set correctly. For example, http://www.frexx.de/xterm-256-notes/ provides you several shell scripts to do that. Vim 7.3 allows you to run "runtime syntax/colortest.vim".

If you would like to know more about environment variable TERM and how the system deals with it, you could take a look at http://wiki.henryhu.net/wiki/TERM (in Chinese though).

gconf-editor

gconf-editor provides you a little geeky way to tweak Ubuntu configurations. It reads the XML configurations in directory ~/.gconf and /usr/share/gconf, and presents these configurations in a human-readable way. But if you think gconf-editor is not geeky enough, you can always directly modify the files in those directories.

Have fun.

Disable Sticky Edges

Ubuntu 12.04 makes the mouse movement sticky on the edges of a screen. For those of you who are not yet used to it (especially if you are using dual monitors), turn it off in "Display" preference.

Hack Unity Launcher

1. Open up dconf-editor (You may want to use apt-get to install it if not found)
2. Go to desktop => unity => launcher
3. The "favorites" key contains a list of applications shown in the launcher initially
4. If you wonder where are these "xxx.desktop" files, go to /usr/share/applications

Enable Adwaita Theme in Ubuntu 12.04

1. Install gnome-tweak-tool: sudo apt-get install gnome-tweak-tool
2. Go to Appearance settings and choose Adwaita

How to Set Ubuntu Terminal Default Size

Open gconf-editor

Go to desktop => gnome => terminal

Set "exec" to "gnome-terminal --geometry ??x??", where ??x?? is the default size you want.

Update: In Ubuntu 12.04, you can set gnome-terminal's default size in "profile preference => general" without hacking gconf-editor.