Using Git like CVS

Tonight I moved the http://rainbowcinemas.ca sources from phpeclipse and CVS to PDT and Git.

Below are some gotchas and tips for initial repo creation, how to keep the central remote copy up to date, and how to work around complaints about updating master directly from remote. I'm sure there's a better way to do this w/o the need for the workaround, but this is what I found worked.

Initial setup To crawl a directory and create a git project for each subfolder: for d in $(find . -maxdepth 1 -type d -not -name "." | \ egrep -v ".ssh|logs|OLD|download|upload"); do cd $d; \ git init; git add .; git commit -m "initial commit" .; \ cd ..; \ done See also Setting up a shared repository.
Create local clone via commandline git clone ssh://servername/path/to/.git folderToCreateLocally	Create local clone w/ eGit Once your repo is created, you can clone a copy from the remote server onto your local box, and import it into Eclipse (with eGit installed) using File > Import > Git > Projects from Git > Clone... .
Commit local changes via commandline As outlined before, you can git pull, git checkout, git commit, and finally git push your changes. If you encounter an error trying to commit changes back to the repo, see the section below, "Allow a ref update to the currently checked out branch of a non-bare repository".	Commit local changes w/ eGit With eGit, you can pull, push, checkout, commit, merge, etc. using the context menu on a Git project or with the Synchronize view. I don't recommend using any of the change sets / models except the Git Change Set, since the others will tend to show more than is actually needed (like local changes which Git doesn't track).
Allow a ref update to the currently checked out branch of a non-bare repository Update the ~/.gitconfig file on the remote server to look something like this: [user] name = Your Name email = your@email.address [color] branch = auto diff = auto interactive = auto status = auto [core] editor = vim [merge] tool = vimdiff [receive] denyCurrentBranch = warn Retrieve changes into remote repo Because I'm using the remote server to both host http-accessible files AND host the git repo, it's important that changes checked into the git repo be then checked out into the local filesystem so that the local workspace is in synch with the repo's metadata. To pull changes, I use git status (to review changes), git reset HEAD <filename> (to reset specified file, or omit filename to reset all changes) and finally git checkout to retrieve the changed file from the repo into the working directory. Access the server w/o a password prompt To skip being prompted for a password when you connect over ssh, scp, or fish, add your public SSH key to the ~/.ssh/authorized_keys file on the remote server. Access the server via an alias Instead of having to reference the server as username@server when connecting, you can add an entry to your ~/.ssh/config file that looks like this: Host shortName Hostname fully.qualified.domain.name.or.IP.address User yourUsername Port 22

Hudson & Virtual Box: Creating a common share with SSHFS

I've been working a recently with my own Hudson server, setting up Fedora and OpenSolaris images as slave nodes to prototype new ways to build. Tonight I found a very handy trick for mounting shared drives using SSHFS. Kudos to the man page writers -- all the tips I found via Google were outdated or just plain wrong. man sshfs to the rescue!

Step 1: create a folder on the Hudson master / Virtual Box host with files you want to share, eg., /shared

Step 2: create an empty folder on each Hudson slave / Virtual Box guest as a mount point for the shared folder, eg., /shared

Step 3: on the guest, install sshfs, eg., sudo yum install fuse-sshfs.

Step 4: mount the share: sshfs user@hudson-master-host.your-domain.com:/shared /shared

Of course you'll probably want to set up ssh keys and add this to your startup scripts so that the mount happens automatically when the guest is launched, but I'll leave that for next time.

Synergy - multiple computers, one shared keyboard

At the suggestion of my summer co-op student & fellow linux evangelist, Neil Skrypuch, I've installed Synergy and can now control my three systems (desktop + two laptops) from a single keyboard. The most amusing part of this is that I can wrest control of my other half's mouse when she's playing cards to mess up her game.

In all seriousness, this is a very cool app which effectively eliminates my need for a KVM box, and also provides more function than a KVM, since not only can I now control multiple desktops from one place, I can also pass data between them. The best use of this so far is that I can select a URL on one machine and open it with another, as Synergy creates a shared clipboard all desktops can use. Very cool.

Here's how I have it set up:

1. Server: Thinkpad w/ external monitor, keyboard, mouse. Located on left side of desk, with monitor in center of desk.
2. Client #1: Desktop w/ backup keyboard/mouse (out of the way and rarely used). Located on right side of desk
3. Client #2: SWMNBN's Thinkpad (for entertainment purposes only). Located on her desk, right of mine.

All I had to do was create an /etc/synergy.conf:

section: screens
  nickblappy:
  nickbdesk:
  TPAD:
end
section: links
  nickblappy:
    right = nickbdesk
  nickbdesk:
    left  = nickblappy
    right = TPAD
  TPAD:
    left = nickbdesk
end
section: options
  switchCorners = all
  switchCornerSize = 15
  switchDelay = 500
  screenSaverSync = false
  keystroke(alt+left) = switchInDirection(left)
  keystroke(shift+control+alt) = switchToScreen(nickblappy)
end

So, on startup of the Thinkpad (server), I run this alias:

alias SS='killall synergys; sleep 1; synergys'

And on the desktop:

alias SC='killall synergyc; sleep 1; synergyc 192.168.0.123'

As the second Thinkpad is running Windows, I just configure the client to auto-start on login and connect to the server's IP. To suppress warning messages when the server's powered down or travelling, I've set the Logging Level to Error instead of the default Warning.

That's it - it's crazy simple. You can also set linux clients/servers to run on startup, or to use SSH to encrypt data sent between machines.

---

Update:

To encrypt traffic with SSH, you need to do three things:

1. Run OpenSSH on the server
2. Run OpenSSH on the client, with local port forwarding. Here's a snippet of my ~/.ssh/config file:

   Host nickblappy
   Port 22
   Hostname 192.168.0.123
   
   Host localhost
   Port 22
   Hostname localhost
   LocalForward 24800 nickblappy:24800

3. Change your alias to connect to localhost instead of the remote server:

   alias SC='killall synergyc; sleep 1; synergyc localhost'

   - or -

   alias SC='killall synergyc; sleep 2; screen ssh localhost "synergyc -f localhost"'

   (then CTRL-A,D to detach)

My new toy

Decided to make the switch from my crazy-old cellphone to a new one this week, and it arrived yesterday to the usual chorus of barking at the front door.

I'm now the proud owner of a Sony Ericsson W810i, complete w/ 1G of storage for MP3s. Very cool phone; better than my nearly-dead 256M K-BYTE MP3 player. I've only made one actual call on it so far, and the fact that it doesn't come with an actual audio-in jack (2.5 or 3.5mm) is a bit of a turn-off, but it works great for games and music, and sports a 2MP still and video camera.

The first app I had to install was of course Gmail. Being a linux geek, the second was MidpSSH which worked fantastically within a couple minutes (except when I wanted to use an ssh key instead of user/password login, and discovered that OpenSSH doesn't appear to support DSS.) Actually, it was user error. I had MidpSSH configured to use SSH1, not SSH2, so it wasn't even trying to send the key. Anyway, re-RTFM a few hours later solved the problem. I can now ssh to my home machine from my phone! Config steps:

1. Configure SSH settings to prefer SSH2 and to use Public Keys
2. Create a session, configured to use your Public Key
3. Copy your phone's public key to your destination host's ~/.ssh/authorized_hosts file
4. If necessary, enable debug mode on the destination host's sshd instance by editing /etc/ssh/sshd_config and setting LogLevel DEBUG, then restarting the daemon with /etc/init.d/ssh restart
5. Connect!