[Solved] No sound on external speaker for eeePc running Ubuntu

My Ubuntu netbook suddenly stopped having sound from its external speakers. No such problem if using headphone jack.

The solution is simple --> I have accidentally switched "iSpeaker" off in "Volume Control > Preferences"

Joining 2 videos in Ubuntu

sudo apt-get install mencoder

cat video1.mpg video2.mpg > video12.mpg

Delete remote tracking branch in git

# Show remote branches tracked
git branch -r

# Delete one by one
git branch -d -r origin/branch

# Delete with one swoop
git remote prune origin

Authlogic login in rails functional tests

# Place this at the top of test/test_helper.rb
require "authlogic/test_case"

# Activating authlogic in before each test
def setup
  activate_authlogic
  UserSession.create(Factory(:teacher))
end

Manually mount USB hard disk

Ref: https://help.ubuntu.com/community/Mount/USB

# Find details of the hard disk
fdisk -l

# Create directory in /media
sudo mkdir /media/external

# Mount drive
# FAT16 or FAT32
sudo mount -t vfat /dev/sdb1 /media/external -o uid=1000,gid=100,utf8,dmask=027,fmask=137

# NTFS
sudo mount -t ntfs-3g /dev/sdb1 /media/external

# Unmount before plugging out
sudo umount /media/external

ignore files that are already tracked in git

Scenario:

"log/test.log" has already been "git added" but I wanna ignore any further modifications made to the file.

Solution: Update .gitignore and run "git update-index"

# .gitignore

log/**/*

# run git update-index

git update-index --assume-unchanged log/test.log

git date spec, ordinal spec, carrot parent, tilde spec

http://book.git-scm.com/4_git_treeishes.html

Date Spec

The Ref Log that git keeps will allow you to do some relative stuff locally, such as:

master@{yesterday}

master@{1 month ago}

Which is shorthand for 'where the master branch head was yesterday', etc. Note that this format can result in different shas on different computers, even if the master branch is currently pointing to the same place.

Ordinal Spec

This format will give you the Nth previous value of a particular reference. For example:

master@{5}

will give you the 5th prior value of the master head ref.

Carrot Parent

This will give you the Nth parent of a particular commit. This format is only useful on merge commits - commit objects that have more than one direct parent.

master^2

Tilde Spec

The tilde spec will give you the Nth grandparent of a commit object. For example,

master~2

will give us the first parent of the first parent of the commit that master points to. It is equivalent to:

master^^

You can keep doing this, too. The following specs will point to the same commit:

master^^^^^^
master~3^~2
master~6

Narrow down to a bad commit with git bisect

http://book.git-scm.com/5_finding_issues_-_git_bisect.html

Finding Issues - Git Bisect

Suppose version 2.6.18 of your project worked, but the version at "master" crashes. Sometimes the best way to find the cause of such a regression is to perform a brute-force search through the project's history to find the particular commit that caused the problem. The git bisect command can help you do this:

$ git bisect start
$ git bisect good v2.6.18
$ git bisect bad master
Bisecting: 3537 revisions left to test after this
[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]

If you run "git branch" at this point, you'll see that git has temporarily moved you to a new branch named "bisect". This branch points to a commit (with commit id 65934...) that is reachable from "master" but not from v2.6.18. Compile and test it, and see whether it crashes. Assume it does crash. Then:

$ git bisect bad
Bisecting: 1769 revisions left to test after this
[7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings

checks out an older version. Continue like this, telling git at each stage whether the version it gives you is good or bad, and notice that the number of revisions left to test is cut approximately in half each time.

After about 13 tests (in this case), it will output the commit id of the guilty commit. You can then examine the commit with git show, find out who wrote it, and mail them your bug report with the commit id. Finally, run

$ git bisect reset

to return you to the branch you were on before and delete the temporary "bisect" branch.

Note that the version which git-bisect checks out for you at each point is just a suggestion, and you're free to try a different version if you think it would be a good idea. For example, occasionally you may land on a commit that broke something unrelated; run

$ git bisect visualize

which will run gitk and label the commit it chose with a marker that says "bisect". Choose a safe-looking commit nearby, note its commit id, and check it out with:

$ git reset --hard fb47ddb2db...

then test, run "bisect good" or "bisect bad" as appropriate, and continue.

View commit difference with breakdown of commit details of individual changes files in each commit

git whatchanged BRANCH..ANOTHER_BRANCH

Show only difference in commit logs between 2 git branches

git log A_BRANCH..ANOTHER_BRANCH

# with diff output
git log -p A_BRANCH..ANOTHER_BRANCH