Wonderland

I recently set up a new repository on github. Creating the repository on github yields a page of instructions covering the two common scenarios: new and existing repositories. After following the new repository instructions, I had a repository on github, a local repository, and the following in response to my git pull command:

You asked me to pull without telling me which branch you want to merge with, and 'branch.master.merge' in your configuration file does not tell me either.  Please name which branch you want to merge on the command line and try again (e.g. 'git pull <repository> <refspec>'). See git-pull(1) for details on the refspec.

If you often merge with the same branch, you may want to configure the following variables in your configuration file:

  branch.master.remote = <nickname>
  branch.master.merge = <remote-ref>
  remote.<nickname>.url = <url>
  remote.<nickname>.fetch = <refspec>

See git-config(1) for details.

Not exactly what I wanted, and certainly not what I expected. What I expected was a local repository with the upstream for master to be set to point at master on the github repository.

Setting this up can be done easily in two similar ways:

• You can edit the configuration file as directed by the error message
• You can use git config

I opted for git config as it was easier and required no thinking—the commands are always the same¹; here they are:

% git config branch.master.remote origin
% git config branch.master.merge refs/heads/master

¹ For the scenario of a local empty repository pushed up to a remote, where the remote will be the upstream master.

The usual autotest workflow goes something like this:

• Edit and save
• Autotest runs associated specs
• Are there failures? Fix and start over
• Autotest runs the entire suite

Sometimes though, you want autotest to just ignore most of your specs and focus on a few specs.

Last week, while Kevin, Rick, and Yossef (OG) were here, they shared an autotest tweak that does exactly that.

The tweak allows you to specify a regular expression to limit the files which autotest watches; for example, to autotest only files matching *user*.rb you would (atest is an alias):

% atest user

Here is the (lightly modified) code to do this; in your .autotest file add:

if ENV['AUTOTEST'] and not ENV['AUTOTEST'].empty?
  only_these_files_re = Regexp.new(ENV['AUTOTEST'])

  Autotest.send(:alias_method, :real_find_files, :find_files)
  Autotest.send(:define_method, :find_files) do |*args|
    real_find_files.reject do |k, v|
      !only_these_files_re.match(k)
    end
  end
end

And in your .bash_profile add:

# Autotest
  function fn_autotest() {
    AUTOTEST=$1 autotest
  }
  alias atest='fn_autotest'

Now use the alias to invoke autotest. For standard autotest behavior:

% atest

To limit what autotest is watching, pass a regular expression (which can be a simple string):

% atest user.*html

David Heinemeier Hansson recently gave an awesome talk titled The secret to making money online at the Y Combinator Startup School. Aside from being entertaining, David keeps hammering at the VC-fueled dreams of today’s web entrepreneurs. David has been at this for a long time, and what he is saying is obvious and common-sense (and David will tell you so).

And yet, we always hear people talking about the Money Maker, or how they are going to target 1% of a $10 billion industry, or other self-defeating filters. If you find yourself uttering those kind of phrases in response to your own ideas or the ideas of others, stop.

Refocus on what the idea is, and evaluate it on its merits. Thinking about how to build a GYM acquisition or targeting a market that will attract $10 million in VC funding is a waste of your time.

Should you ignore pricing and profits? Maybe; if you do look at them, examine them in a reasonable context—what do I need to just run the service on a minimal server? With no paid staff? With minimal time commitments? How would it look like if I had 100 customers? 1000 customers?

Yes, this means you are no longer playing in the VC startup space¹. Cool. If you really want to play there, you will be much better off playing there after you already have those 100 customers.

¹ I am unsure about investors like Y Combinator, as they seem to be advocates for this way of thinking.

Seth Godin has just put up a fantastic post on The intangibles—ways to set your product or service apart.

Many of them read as common-sense or obvious, but like most common-sense and obvious advice, it is rarely actually practiced; often the advice is even actively dismissed with an annoyed ‘Of course we do that!’—only you do not do that, and you are fooling yourself by saying so.

Take stock of what you are doing, and ask yourself if you are really doing the common-sense and obvious things.