basic git

Sometimes I get asked, “hey I want to learn git, what should I do?”. My answer is usually somewhere between read the Pragmatic book, watch the Peepcode, or “hey, there are only a few commands you’ll use 80% of the time, I should write them down.”

So if you just need some basic git, just to get by, this post is for you. Note that this just glosses over the basic commands, you’ll want to use the man pages and resources on the web such as the free book Pro Git to learn more.

git clone

This makes a copy of the passed repository and puts it on your machine. Note that git clone will create the directory called ‘ext-extensions’ for you. This is the first step to working with an established repository.

$ git clone git@github.com:jjulian/ext-extensions.git

git stat

git diff

git stat tell you the current status – what files have changed. And git diff will show you a line by line diff of every file that has changed. Pipe it’s output to your favorite editor, or to a pager like less.

git commit

$ git commit -m "added this new feature" ext-extensions.js

You have just added your change into your copy of the repository. Pass a meaningful message. You need to specify the file(s) to commit, or -a to commit everything that is modified.

git push

Use git push to send all your commits to the origin server. If you don’t want to send them all, then commit some on a different branch from ‘master’. (this is not hard, but a bit more advanced. Look up git branch and git checkout).

$ git push origin master

That’s the remote repo name (origin) and the branch name (master). These are defaults; you can push/pull to/from more than one remote repo.

git pull

Use git pull to integrate changes from another git repo into yours. Similar format as git push.

$ git pull origin master

Armed and dangerous

Armed with the above commands, and a git expert nearby, I guarantee you’ll be able to survive the day only bothering them once or twice. Here are more tips to keep you going:

git add

You can batch your commits to git. Use git add to queue up a bunch of files (or directories) and then commit them all at once using git commit. Very helpful. With this usage, do not specify files on the command line. If you use git add, you also need to use…

git diff –cached

the –cached param to diff tells it to diff against the version pending commit, not the version on disk. This can get you in trouble, so before you commit ‘added’ files, make sure you have not changed them since the add (of course, this is a feature as well, as you can keep modifying a file but then only commit the original changes. It can get confusing, so just don’t do it.).

git checkout — path/to/file.txt

You’ve made some changes to a file, maybe lot’s of changes, and it’s all crap. You just want to pull the latest version from the repo and forget you even edited it. This works alot like svn revert.

These are the commands I use every day. There are some more: git log, git merge, git mv, git rm, git reset, git show, git blame…but I’ll save these for part 2. The basics are enough to allow a user without too much scm experience to survive changing code and committing files. There’s plenty of info available on the web for any git situation you may find yourself in, don’t be afraid, jump on in!

rake jslint

JSLint is one of the most valuable tools for a JavaScript developer. Short of being a “compiler”, it’s a “code quality tool” that can keep you from doing things that may come back to haunt you in the future. I’ll leave the detailed explanation to the author, Douglas Crockford – I assume you’re reading this because you want to integrate jslint into your Rails project and run it on the command-line!

To run jslint as a rake task in your Rails project, you’ll only need a few things:

  • the Java runtime
  • Rhino, the java-based javascript runtime environment
  • jslint itself
  • a rake task to invoke it

So let’s get it set up. First, the java. Drop into a shell on your development system (or build system, wherever you want to run jslint), and make sure you have access to the java runtimes (run java -v, or which java). If not, go get it. Don’t be afraid, it’s easy.

Next you’ll need Rhino, the javascript execution environment. There are many js implementations (spidermonkey/treemonkey, v8, etc), but Rhino is the one that Crockford chose when he wrote the extension to jsunit that loads a file to be parsed. Its a jar file, go get it and put it into your project as vendor/rhino.jar.

Now you need Crockford’s jslint code. There are two parts: one is jslint.js, and the other is the Rhino extension (rhino.js). We will need both of these, and I’ve found it’s easiest when they are combined into one. Concatenate rhino.js to the bottom of jslint.js and save as vendor/jslint.js.

Hey, we’re almost there! Now you just have to add the rake task to your project.

Drop this gist into an existing Rakefile, or rake task. If you don’t have any rake tasks, then simply save this as lib/tasks/jslint.rake. Rake will find it in your project automatically. Run rake -T to confirm.

A short explanation: it finds all the js files you want to inspect, and runs jslint on them one at a time, printing out failures. Line 6 is the key line – you can change two parts of this to suit your project. First, the list of files to check is created using a Dir glob. My example gets all *.js files under /public recursively (**). Then the second part of that line is used to reject js files you DO NOT want to inspect. Frameworks, 3rd party code, for example (although it can be fun to run jslint on your framework code to see their level of quality). This example excludes the ExtJS installation.

Now youre ready to run

rake jslint

and enjoy the benefits of quality-checking your JavaScript code! And since you’ve just built a rake task that returns 0 or 1, it can be easily integrated into you automated or continuous build process. Heh heh – now the build will fail and everyone will know who doesn’t use triple-effing-equals! (see slide 13 of Naked JavaScript)

Enjoy command-line jslint. And if you develop using TextMate, I highly recommend integrating jslint into that as well.

(I’ve been thinking and talking about this for too long. Inspiration to finally get command-line jslint set up came from reading this stackoverflow earlier today.)

JavaScript: The Good Parts

A few weeks ago, Shea Frederick asked me if I could put together a presentation for the July meeting of the Baltimore/DC JavaScript Users Group. We talked about some of the things we’ve been working on, and I mentioned that I’d been reading JavaScript: The Good Parts, an amazing book by Douglas Crockford. And a “book review” style presentation was born.
I decided that since the book is so dense with js knowledge, I’d just pull out my favorite takeaways and put them into a 30 minute presentation.
I didn’t spend too much time polishing the slides (or my delivery), so it came off more as a discussion than a “presentation”. It was fun. The 10 or so folks in the room chatted about the virtues of a loosely-typed language, debated about whether == is truly evil, and were truly grossed out by one of the images in the deck.
It was fun. I think next time, I’ll spend more time in spidermonkey doing some live coding, as well as showing off JSLint running on the cmd-line. And brush up on some language details - Jay Garcia schooled me on why the === works (it internally compares types before comparing values). My only regret is that I missed the jalapeno & pineapple pizza.