Forem: Kyle Chilcutt

Smarter git checkout with fzf

Kyle Chilcutt — Thu, 30 May 2019 07:00:00 +0000

After I’ve been working on a project for a while, I tend to have a list of multiple branches of work a repo. When jumping between branches on a project, my workflow is usually something like:

git branch
find the branch I want to jump to
highlight the branch name in the terminal
copy the branch name
checkout the branch with git checkout <paste>

This isn’t too bad, but could it be better?

I’ve been using fzf to speed up my workflow on the command line and in vim (as a replacement for ctrlp) for a little while, but it recently occurred to me that you could also pipe fzf into a command.

This is extremely useful as you can use it to create an ad hoc UI for making a selection as part of a command.

The fzf utility gives us some new flexibility, now instead of needing to use my mouse to cut-and-paste the branch name I want, I can select the branch name using fzf.

After a little bit of experimentation, I came up with:

$ git for-each-ref --format='%(refname:short)' refs/heads | fzf | xargs git checkout

This oneline uses for-each-ref, a low-level command for scripting, to get a list of all the local branches in the repository without any decoration. The result is piped to fzf where we can select the branch we want and finally the result is passed through xargs so we can git checkout the branch.

The last step was to wrap this up in an git so it’s always avaialble to me from my gitconfig.

$ git config --global alias.cof $'!git for-each-ref --format=\''%\(refname:short\)\'' refs/heads | fzf | xargs git checkout'

In the above, I’ve configured cof for “checkout fuzzy” and I fought with the bash escape characters so you don’t have to.

Zooming a pane in Vim

Kyle Chilcutt — Fri, 26 Apr 2019 15:31:00 +0000

Photo by Paul SkorupskasonUnsplash

When coding with vim, I tend to pretty heavily use split panes and tabs in my workflow. Having different files open side-by-side helps me trace through the code to identify where I need to make changes.

Once I find where I want to make an edit, I usually want to shift my focus to just one file. That’s where a handy little plugin called ZoomWin comes in. With the ZoomWin package installed I can just toggle zooming a pane with <c-w> o (control + w, followed by o).

RSpec nested subjects

Kyle Chilcutt — Wed, 24 Apr 2019 15:21:23 +0000

The RSpec subject functionality can be useful for simplifying your spec setup and getting straight to the point. I really like using an explicit subject because it helps describe what functionality is under test when you’re writing your specs. Recently, I learned it was possible to nest your subject when using a named subject.

Photo by Clément H on Unsplash

The subject syntax allows you to use the one-liner syntax for writing a test which can really clean up a spec file. Let’s take a trivial example of a Rails model:

describe Car do
  let(:car) { Car.new }

  it "is a vehicle" do
    expect(car).to be_a(Vehicle)
  end
end

For this trivial case, you’ll notice that our expectation pretty literally matches the description of the test case. This might be a good use case for subject:

describe Car do
  subject { Car.new }

  it { is_expected.to be_a(Vehicle) }
end

The above will test the same functionality and also leave pretty similar spec output when the spec is run.

Failures look slightly different, but make the same point.

You can also redefine your subject for different blocks of your test. Let’s set the subject for an instance method that I want to test:

describe Car do
  subject { Car.new }

  it { is_expected.to be_a(Vehicle) }

  describe "#parked?" do
    subject { Car.new.parked? }

    it { is_expected.to eq(false) }
  end
end

Dope. By redefining the subject we can use the one-line syntax wherever we want.

The final trick is we can add an name to our initial subject so we can reference it later within the spec:

describe Car do
  subject(:car) { Car.new }

  it { is_expected.to be_a(Vehicle) }

  describe "#parked?" do
    subject { car.parked? }

    it { is_expected.to eq(false) }
  end
end

I find this particularly useful if the subject in the enclosing block has some complex setup:

describe Car do
  let(:driver) { Person.new }
  let(:front_seat) { Person.new }
  subject(:car) { Car.new(driver: driver, front_seat: front_seat) }

  it { is_expected.to be_a(Vehicle) }

  describe "#parked?" do
    subject { car.parked? }

    it { is_expected.to eq(false) }
  end
end

Now we can leverage any earlier setup while still having the benefits of different subjects in each context.

Shout out to Zack Mariscal for helping me edit and improve this post and my writing in general.

Auto-correct git spelling mistakes

Kyle Chilcutt — Fri, 19 Apr 2019 14:13:41 +0000

I use git a lot for both work and personal projects, which means I type a lot of commands each day. git has a built-in spelling auto-correct system for when you’re not quite having the most precise day.

tl;dr auto-correct git spelling mistakes

$ git config --global help.autoCorrect 1

This turns this:

aarrggghhhh

To this:

aww yiss

$ git config --global help.autoCorrect 1

The argument is the number of deciseconds (0.1 sec) to wait before correcting and executing a command and 1 is the shortest possible delay. If only a single option is found it will be executed, if multiple commands could be possible, it will error and ask you to try again:

Combined with a handful of bash aliases for the ways I commonly misspell git and there’s a chance I can get some stuff done without that extra cup of coffee.

$ alias gi='git'
$ alias gti='git'
$ alias gits='git'

I probably accidentally use this git config more than any other…

git current

Kyle Chilcutt — Wed, 17 Apr 2019 07:00:00 +0000

As an avid vim user, I have a weird aversion to ever using the mouse/trackpad to do anything–especially while at the command line. I noticed that one common thing for me to do was to run git branch or git status to see what branch I was on in order to use the branch name in another command. I didn’t like that.

tl;dr create a git alias for seeing your current branch:

$ git config alias.current "rev-parse --abbrev-ref HEAD"
$ git current # displays the current branch

The aliased command prints the current branch that you’re on to STDOUT:

Once we have the alias created, we can do this even more simply:

The real beauty of the command is when you use it to compose another shell command. Let’s say I’m about to take on a few complicated and potentially dangerous operations and I want to create a backup branch because I don’t like spelunking the ref list if I can avoid it. I can easily create a backup branch based on the same name now:

Useful in a case with a more complicated base branch name...

Or if I realize I’ve gone down the wrong path and need to start over:

Being lazy sometimes sparks some cool ideas for minor tips/tricks/hacks that just make work more enjoyable. What are your favorites?

Ad-hoc reverse SSH for getting things from remote locations

Kyle Chilcutt — Fri, 05 Apr 2019 07:00:00 +0000

As a web developer, I’m often working with remote servers over SSH. Sometimes I’m working with a file on the remote server and want to get it back to my local machine (e.g. script output, a CSV, or a log file). One way I can easily get them back is by opening a reverse SSH port along my connection to the server.

tl;dr open a reverse connection to your local computer and scp a file home

# from the remote shell, get into the SSH prompt
$ <enter> ~C

ssh> -R 127.0.0.1:2222:127.0.0.1:22

$ scp -P2222 move_this_file.txt kyle@127.0.0.1:~/Downloads

Let’s take a look at what’s going on here.

$ <enter> ~C

That’s the “enter” key, followed by a “tilde”, followed by a capital “C”. This string of keystrokes will get you into the ssh command line and give you a new prompt.

ssh> -R 127.0.0.1:2222:127.0.0.1:22

From the new prompt we’re going to request a remote forward port…

ssh> -R 127.0.0.1:2222 :127.0.0.1:22

From the remote machine on port 2222…

ssh> -R 127.0.0.1:2222: 127.0.0.1:22

To the local machine on port 22.

Once this is set up, we can see a forwarded port opened on port 2222:

$ netstat -nap | grep 2222 tcp 0 0 127.0.0.1: 2222 0.0.0.0:*

We can then use this port to connect to the SSH server on the local machine and move any files using the scp command (or any command that can use the SSH connection).

$ scp -P2222 move_this_file.txt kyle@127.0.0.1:~/Downloads

In the case above, I’m sending the file named move_this_file.txt to my local machine in my Downloads folder off my home directory.

When you close the SSH connection to the remote server, the port forward will also be closed.

If you’re on MacOS, you have an SSH server preinstalled on your machine that’s not active, you can turn it on from the command line:

$ sudo systemsetup -setremotelogin on

If you’re forward thinking enough, you can open this SSH remote port forward when you first connect to the remote server:

$ ssh -R 127.0.0.1:2222:127.0.0.1:22 remote_user@remote_server

I don’t usually anticipate that far ahead…

nohup for running remote scripts

Kyle Chilcutt — Thu, 04 Apr 2019 07:00:00 +0000

I’ve been aware of nohup for a while, but never took the time to do a deeper dive until today.

tl;dr run a command that won’t die when you log out (useful for tasks on a remote server)

$ nohup my_long_running_script > script_results.out 2>&1 &

The nohup utility lets your run another command that is immune to hangups, meaning that it won’t die when you log out of the machine. This is particularly useful for when you’re connected to the terminal of a remote machine (e.g. using ssh).

Let’s break down the example from the beginning:

$ nohup my_long_running_script > script_results.out 2>&1 &

The nohup utility causes the script being run to be immune to SIGHUP, the signal which is sent to a process when the terminal controlling it is closed.

$ nohup my_long_running_script > script_results.out 2>&1 &

The next part is running the command as usual and sending the output to a text file. Because we’re going to disconnect from this terminal session, we’re not going to be observing the output live as the script runs. To capture the output, we direct the output to a file script_results.out.

$ nohup my_long_running_script > script_results.out 2>&1 &

2>&1 redirects STDERR to STDOUT, which will allow us to capture both normal output and error output in our results file.

$ nohup my_long_running_script > script_results.out 2>&1 &

The final & causes the nohup command to be run in the background, so that we’re returned immediately to the shell once the command has been started.

Prior to this, I might have started a tmux or screen session on the remote machine to make sure the script cannot be interrupted, but nohup feels a lot more straight-to-the-point.