But these little setbacks are sometimes just what we need to take a giant step forward, Right Kent?

maintaining SSH_AUTH_SOCK in tmux

Tmux has a neat feature where certain environment variables can be updated during attachment.

SSH_AUTH_SOCK is included by default. When you reconnect from within a new ssh environment, SSH_AUTH_SOCK is updated inside of tmux. Any new windows created in the tmux session will have the updated ssh information.

Already running shells are not updated (how would tmux tell the shell to update?). I've added a zsh alias to my workflow to pull in the updated value from a running shell. It wraps the show-environment tmux command. This is a shell alias because it needs to affect the running shell.

fix_ssh () {
        eval $(tmux show-environment | grep ^SSH_AUTH_SOCK)
}

I don't normally start many interactive ssh session from my remote box, but I do need to talk to my local SSH agent to connect to my private git repos. I hate running an update and seeing Permission denied. Before I added this fix_ssh command, I caught myself opening new tmux windows to run the fetch from and then closing them to return to my active shell -- an expensive and distracting work-around.

% git fetch
Permission denied (publickey).
fatal: Could not read from remote repository.
% fix_ssh
% git fetch
# success!

When I run with screen, I set the SSH_AUTH_SOCK value to a steady value before opening the initial screen session and then manually update the sock on each login. When I remember.

# for screen
MY_SSH_AUTH_SOCK=$HOME/.ssh/auth_sock
rm $MY_SSH_AUTH_SOCK && ln -s $SSH_AUTH_SOCK $MY_SSH_AUTH_SOCK && export SSH_AUTH_SOCK=$MY_SSH_AUTH_SOCK

Interview with an adware author.

It was funny. It really showed me the power of gradualism. It’s hard to get people to do something bad all in one big jump, but if you can cut it up into small enough pieces, you can get people to do almost anything.

http://philosecurity.org/2009/01/12/interview-with-an-adware-author

how-to: run git interactive rebase non-interactively

TL;DR

git alias to autosquash fixup commits non-interactivly:
git config --global alias.fixup '!GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash'

non-interactive interactive rebase

In the normal workflow, git interactive rebase presents the user with a document to edit interactively to modify and reorder commits. What if you want to run it non-interactively?

Yes, you can do this. And yes I have a use-case!

I'd like to apply/squash all my --fixup commits automatically without spending time in that editor screen. This is an easy use case because I don't change anything in the editor window, that's handled by the --autosquash flag to rebase.

-i
--interactive
Make a list of the commits which are about to be rebased. Let the user edit that list before rebasing. This mode can also be used to split commits (see SPLITTING COMMITS below).

The commit list format can be changed by setting the configuration option rebase.instructionFormat. A customized instruction format will automatically have the long commit hash prepended to the format.
-- git rebase documentation

Git respects the traditional unix environment variables $EDITOR and $VISUAL. Overriding one of those will change the editor that is run during interactive rebase but also changes the editor used while in the rebase to change commit messages and etc.

A third environment variable was added by Peter Oberndorfer: $GIT_SEQUENCE_EDITOR. This editor is only used for the interactive rebase edit. As an aside, this is a wonderful commit message.

"rebase -i": support special-purpose editor to edit insn sheet

The insn sheet used by "rebase -i" is designed to be easily editable by any text editor, but an editor that is specifically meant for it (but is otherwise unsuitable for editing regular text files) could be useful by allowing drag & drop reordering in a GUI environment, for example.

The GIT_SEQUENCE_EDITOR environment variable and/or the sequence.editor configuration variable can be used to specify such an editor, while allowing the usual editor to be used to edit commit log messages. As usual, the environment variable takes precedence over the configuration variable.

It is envisioned that other "sequencer" based tools will use the same mechanism.

Signed-off-by: Peter Oberndorfer
Signed-off-by: Junio C Hamano

-- http://git.kernel.org/cgit/git/git.git/commit/?id=821881d88d3012a64a52ece9a8c2571ca00c35cd

Did I just know all this? No, not really. I hadn't heard of GIT_SEQUENCE_EDITOR until reading the code for the silly little git --blame-someone-else script going around. That gave me the keyword to search to find this excellent Stack Overflow answer.

Autosquash

For my usage, I just need an editor that completes successfully without modifying the input. Luckily I have one of those, a bunch really, but lets go with the simplest:true. Yep, this will run an autosquash interactive rebase without showing me the pick window, where $COMMIT_SHA is the reference for the rebase.
GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash $COMMIT_SHA

By defining the environment variable at the start of the command, it is only stored in the environment for that command.

I've now stored this as a git alias to test out. I'll let you know how it goes.
git config --global alias.fixup '!GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash'

Examples

git fixup master

rebase the current branch to HEAD of master and autosquash the commits.

rust: to_string() vs to_owned() for string literals

Always use to_owned() to convert a string literal.

I found this lovely explanation of to_string() vs to_owned() for rust. Only use to_string() for other types that can convert to string.

You should always be using to_owned(). to_string() is the generic conversion to a String from any type implementing the ToString trait. It uses the formatting functions and therefor might end up doing multiple allocations and running much more code than a simple to_owned() which just allocates a buffer and copies the literal into the buffer.
-- https://users.rust-lang.org/t/to-string-vs-to-owned-for-string-literals/1441

With the caveat that this may be fixed in the future to optimize to_string() on String literals.

This may be fixed in the future with specialization, as str could implement ToString directly instead of having it go through the generic impl ToString for T where T: Display {} implementation, which employs the formatting framework. But currently I do concur with your recommendation.
-- DroidLogician

SCALE14x

I'm presenting at SCALE 14x on Sunday January 24, 2016.

Fix the Website: a devops success story (details)

Here are my slides!

1. Original Keynote file
2. PDF
3. pdf with presenter info