Satya's blog

Oct 18 2014 07:26 git branches and git add -p

So you made some changes and want to commit to two different branches?

You have this:

$ git status

modified: foo
modified: bar

You want foo on branch A and bar on branch B. Easy enough:

$ git co A
$ git add foo
$ git commit
$ git co B
$ git add bar
$ git commit

You want foo on branch A along with one of your changes from bar. You want the other changes in file bar on branch B.

$ git co A
$ git add foo
$ git add -p bar
$ git commit
$ git co B
$ git add bar
$ git commit

Note the "git add -p bar". At that point, git will ask you, interactively, which changes you want to include in the changeset.

What if branch B doesn't exist yet? Instead of simply doing 'git co B' you would do 'git co -b B'.

At some point, you have a local branch that has never been pushed to the origin (that's just the usual name for the primary remote repo, btw). You can push the branch like this:

$ git push origin B

That pushes the current branch to a branch named B on origin. You could be on branch B, and do this:

$ git push origin C

And you've just pushed to a branch named C, and confused your future self.

Suppose you want to set up the remote branch and the local branch should track it. So that git status will show you things like "Your branch is ahead of origin/B by 10 commits [ you should push]" and also so that you can, in future, simply run `git push`. Then you'd do this on the first push:

$ git push -u origin B

And subsequent pushes would just be:

$ git push

Tag: howto git

Jun 29 2014 22:40 Git branching tips

When creating a branch with git:

git co -b new_branch_name

This says make a branch named new_branch_name and switch to it.

When the time comes to push it to your remote server:

git push -u origin new_branch_name

This says push the current branch to origin (your default remote server) and call it new_branch_name on origin, and also set up to track that remote branch (-u). Tracking means, when you're on this branch and do git pull, git knows which branch to merge into this one. And git status tells you useful things like "Your branch is ahead of origin by 1 commit".

Tag: git

Mar 23 2014 09:33 Vim
blockquote> "The composability of vim commands is a beautiful thing."

agumonkey on HN
https://news.ycombinator.com/item?idb47849

Meaning that you can put vim commands together to make new commands.

Dec 08 2013 08:28 VIM encoding
So you just pasted from Excel into vim and now there's unicode in your ACSII? The easiest way to fix that is to type
set encoding=iso-8859-1
at the colon prompt. (Yes, I know I said ASCII.) You'll be able to see the extra unicode bytes and delete them.
Dec 16 2012 07:55 CLUI: Command Line User Interface
CLUI: Command line user interface. One of those comamnd-line based interfaces, usually built with ncurses, that provides a simplified GUI so you don't have to type actual commands. Example: aptitude, midnight commander, pine, mutt.

Tag: geeky

Nov 08 2012 22:08 Desktops
My desk, running Windows, Mac, and Linux all at the same time on 3 different computers:
Nov 04 2012 19:13 Do I have a startup?

Clay Allsop says having a startup means one of: you've raised money, are bringing in substantial revenue, or have a sizable active user base.

I have a side-project, a web application to manage the academic data for students of speech pathology. I'm a contractor, but in Silicon Valley terms, I'm the tech co-founder and probably CTO.

We've been around since 2005, in one form or another. In about 2009, we spun-off from the institution where the project started, and started taking on paying clients.

Right now, we have 32 institutions that are using the product, with about 8 more in the wings. Each institution has anything from 10 to 100 students. There's our sizable active user base.

We don't have substantial revenue by startup standards , but it is comfortable for a side-project.

We haven't raised, nor attempted to raise, any funding. We're just going by our day-job paychecks, savings, and revenue.

So by Clay's definition, it's a startup. It's not successful (yet), since it can't be all our primary jobs and pay all our salaries.

It can be successful, though, because between the founders we have considerable domain knowledge, technical knowledge, and domain contacts. The business person is a speech pathologist and former professor, which is how this thing got started. Knowing exactly what the customer wants is *gold*.

We don't need to advertise. The user base, speech pathology faculty, are a close-knit bunch (apparently) who love what we have so far. And what we have is a fully functional, post-MVP (Minimum Viable Product, i.e. the least number of features you can release that forms something usable), product.

Do I have a startup? Yes. Is it viable? Probably. Can I get funding? Don't know.

Sep 23 2012 16:12 Migrating a subversion repository to git

I used these instructions to migrate some svn repositories to git:
http://john.albin.net/git/convert-subversion-to-git
But I don't have the svn standard layout, with trunk/ branches/ and tags/, so I was able to skip several steps. My condensed flow was:

Retrieve a list of all Subversion committers:

svn log -q | \
awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' \
| sort -u > authors-transform.txt

Edit that file as appropriate.

Clone the Subversion repository using git-svn: Here, I didn't use the --stdlayout argument:

git svn clone [SVN repo URL] --no-metadata -A authors-transform.txt ~/temp

Convert svn:ignore properties to .gitignore: Not required if you didn't have any svn:ignore properties

cd ~/temp
git svn show-ignore > .gitignore
git add .gitignore
git commit -m 'Convert svn:ignore properties to .gitignore.'

Push repository to a bare git repository: I didn't link HEAD to trunk, I linked it to git-svn:

git init --bare ~/new-bare.git
cd ~/new-bare.git
git symbolic-ref HEAD refs/heads/git-svn
cd ~/temp
git remote add bare ~/new-bare.git
git config remote.bare.push 'refs/remotes/*:refs/heads/*'
git push bare

Then delete ~/temp

Rename git-svn to master (instead of renaming trunk):

cd ~/new-bare.git
git branch -m git-svn master

And, since I had no branches, just rename/move new-bare.git to the final resting place, and then clone it out.

Tag: howto

Aug 02 2012 22:58 Yoda conditions and spectacular failure

At http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html there is some talk of "Yoda Conditions". I sent an email to someone explaining what that is, as follows:

So, Yoda speaks "backwards", right? In many of the languages in common use, "=" is for assigning values to a variable and "==" is for comparison. A common bug used to be assignment instead of comparing. Usually assignment evaluates as "true" in the comparison context.

Suppose some variable 'i' is 3. "if i=5" will set i to 5 *and* cause the program to think that the condition has come about. But i was actually 3 and would have failed comparison when correctly written as "if i==5".

The code will execute fine, but not produce correct results. So some IDEs (code editors) warn you that you're assigning when you should be comparing. To help you when not using those IDEs (which is often), some programmers write "if 5==i" which is a perfectly valid comparison. If typed as "if 5=i" it will NOT COMPILE and thus will never execute and will never be subtly wrong.

Spectacular failure (crash, or 500 internal server error) is better than subtle failure (grade is B- where it should be B, or vice versa) because spectacular failure is immediately noticeable and doesn't lead you to think you have the right results when you don't.

Tag: geeky

May 29 2012 21:35 Rails 3 on Ubuntu with RVM

(See old article http://www.thesatya.com/blog/2011/05/rails3_upgrade.html )

sudo apt-get install git-core curl libmysql-ruby 

sudo apt-get install libmysqlclient-dev libsqlite3-dev

Install rvm from the rvm website, usually with something like:

curl -L get.rvm.io | bash -s stable
also add to your .bashrc or equivalent:
[[ -s ~/.rvm/scripts/rvm ]] && source ~/.rvm/scripts/rvm

Install pre-requisites, and ruby, and set the default ruby:

rvm pkg install zlib
rvm install 1.9.2 #or 1.9.3
rvm default 1.9.2

Then you can put .rvmrc files in your project directory (or a new directory) containing something like:

rvm use ruby-1.9.2-p180@my_gemset_name --create

Then you can set up a Gemfile, and then run:

gem install bundler
bundle install

Tag: rails ubuntu

Apr 14 2012 22:55 Behavior Driven Development

In response to a post at http://37signals.com/svn/posts/3159-testing-like-the-tsa

Don't aim for 100% coverage.

Nope, please test as much as you can. It's ok to break out things like:

function goto(url) {
 window.location = url;
}

and not test the goto function, though. Also, don't test other people's code.

Code-to-test ratios above 1:2 is a smell, above 1:3 is a stink.

Perhaps. but what's the metric? I hope it's not LOC.

You're probably doing it wrong if testing is taking more than 1/3 of your time. You're definitely doing it wrong if it's taking up more than half.

I think we do this sometimes. If we can't imagine how to test something, I think that's a smell of testing other people's code, or testing too granularly. Perhaps an integration-style test, or a behavior-driven test, would work better. Do we really need to test that this method sets the right call stack and calls the right 45 methods in ActiveRecord? Or do we want to start with a CSV file and empty DB, run the method under test, and at the end have those records in the DB?

Don't test standard Active Record associations, validations, or scopes.

Don't test other people's code, unless incidentally in a behavior-driven test.

Reserve integration testing for issues arising from the integration of separate elements (aka don't integration test things that can be unit tested instead).

Sure, unless you're behavior-driving.

Don't use Cucumber unless you live in the magic kingdom of non-programmers-writing-tests (and send me a bottle of fairy dust if you're there!)

Cucumber is non-trivial.

Don't force yourself to test-first every controller, model, and view (my ratio is typically 20% test-first, 80% test-after).

Well, depends. If you test-first, you get better coverage and leaner code (code that does only what the test calls for). Behavior-driven development (BDD) is correlated with test-first and better coverage.

The 37signals blog then quoted Kent Beck:

"I get paid for code that works, not for tests, "

So true.

Last updated: Apr 14 2012 23:04

Tag: testing