I've been slowly trying out git and Github and doing some experimenting. Tonight I tested the 'branch' waters. There seems to be some confusion on some blogs regarding managing branches on Github. I think I've got it figured out (at least for my purposes), so for future reference and to maybe help out someone else, here are my notes. This post and this one have some tips that helped me a lot, but they're still a bit confusing and I'm not convinced the authors were very sure what they were doing when they wrote those. (caveat: I'm not really sure what I'm doing either.)

My goal was simply to be able to easily create a local branch, easily commit changes on the branch to Github, and easily merge the branch back into the master. I'll assume that if you want to follow along, you've already got a repository setup on github, a local copy of that repository on your machine, and that you're at the command line in the projects directory, and you're on the master branch. Ok, let's do it.

  #check that we're on the master branch
> git branch
* master

  #create a local branch named flibberty
> git branch flibberty

  #confirm new branch exists
> git branch
  flibberty
* master

  #push the new branch to github
> git push origin flibberty

At this point, if you go to your repository on Github and click 'all branches' you should see 'flibberty' in the list. (If you already had the page loaded, you'll need to reload the page first. Ok, so now lets do something with our branch.

  #switch to flibberty branch
> git checkout flibberty

  # Now make some changes to a file and then...
> git commit -a -m "test committing changes to a branch"
> git push 

  #switch back to the master
> git checkout master

  # Make a different change to a file here, and then
> git commit -a -m "test change committing back to master"
> git push

Ok, now at this point you should be able to swap back and forth between your master and flibberty branches on Github and see the different changes in master and flibberty. You can also go the the "Network" tab and see the map that shows the branch commits parallel to the master. But, wait, what if your co-worker created this branch, and all you've got locally is the master? How can you switch to the branch to make your own changes?

  # create a local branch tied to the one on Github and switch to it.
> git branch flibberty origin/flibberty
> git checkout flibberty

Now, let's imagine we're done making changes to the branch and ready to merge it back into the master.

> git checkout master
> git merge flibberty
> git push

And that's it. The key point here is getting the local branch onto Github, which despite convoluted instructions elsewhere, seems to just be one simple step... git push origin local_branch_name. Easy, huh? One last thing. We're done with the branch, so now we can safely delete it from Github and locally.

  # delete branch from Github (notice the colon!)
> git push origin :flibberty

  # delete local branch
> git branch -d flibberty

I think that command to delete the branch on Github is about is cryptic as it can get, which is my one complaint with git so far. After a couple years of working with Ruby and Rails and getting used to easy to read a lines of code like @user.subscriptions.find(:all, :conditions => {:active => true}) git has been a rude reminder that some programmers seem to go out of their way to be as opaque as possible... and the people that created git (Linus, I'm looking at you!) are apparently in that club.

Comments: 0 [add comment]

If you've got a laptop computer, it's not a bad idea to encrypt a data partition and keep all your personal data there. That way if your laptop gets lost or stolen, then the thief may have your computer, but they won't be able to steal your identity, too. And, doing so in linux is absurdly easy. Here's how I did it on Ubuntu. Also note that, if you've been here before and already have the encrypted partition, but are trying to access it from a new install of Ubuntu, you should *skip* steps 2, 4 & 6

Step 1) Use Synaptic to install the 'cryptsetup' and 'pam-mount' packages.

Step 2) Create a new primary partition that will be your encrypted partition (I recommend using gparted to do this).

Step 3) Restart your computer. This is a step I frequently forget, but is absolutely necessary for the right encryption modules to be loaded into your kernel.

Step 4) Run 'sudo cryptsetup luksFormat /dev/sdXX' where 'sdXX' is the name of the new partition you created in step 2 (eg, sda4). When asked for a passphrase, use the exact same password you use to login to the computer (you'll see why in step 9). Notice and heed the warning "This will overwrite data on /dev/sdXX irrevocably."

Step 5) Run 'sudo cryptsetup luksOpen /dev/sdXX sdXX'

Step 6) Run 'sudo mkfs.ext3 /dev/mapper/sdXX'

Step 7) Create a folder to mount your partition to. I like to use /mnt/sdXX, but you could just as easily put it right in your home directory, such as '~/encrypted'. Note the all instructions below assume you chose '/mnt/sdXX', so adjust accordingly.

Step 8) Run 'sudo mount /dev/mapper/sdXX /mnt/sdXX'

Ok, now your partition is created and mounted. But, next time (and every time) you restart your computer you'll need to run step 8 again. If you forget, you'll find that /mnt/sdXX is empty, and panic. Wouldn't it be nice if you could just mount that partition automatically whenever you log in? Well, as long as you used the same passphrase for the for the partition as your password when you log in, you can.

Step 9) As root, open /etc/security/pam_mount.conf.xml and add or uncomment the line that says '<luserconf name=".pam_mount.conf.xml" />'

Step 10) Create a file named .pam_mount.conf.xml in your home directory and fill it with the following...

<?xml version="1.0" encoding="utf-8" ?>

<pam_mount>

<volume fstype="crypt" path="/dev/sdXX" mountpoint="/mnt/sdXX" />

</pam_mount>

Step 11) As root, edit /etc/pam.d/gdm and add '@include common-pammount' to the end of the list.

Step 12) Reboot and you should find that the encrypted partition gets mounted for you.

One final word of warning. If an UNencrypted partition fails or gets corrupted, there are still some very crude methods to *try* and recover anything that wasn't properly backed up. When an ENcrypted partition fails like this, you can probably throw most or all of those tools and techniques out the window. So, keep your encrypted partition frequently backed up to a different *physical* drive, probably external, probably also encrypted.

Comments: 0 [add comment]