Slaying dragons with git, bash, and ruby | Hacker News Reader

Slaying dragons with git, bash, and ruby

rubypond.com

57 pointsglenngillen17 comments

You should really look at the sample hooks. Instead of of recursively grep'ing the entire source tree, you can look at just what is being committed. For example, for pre-commit you can do this instead:

  #!/bin/sh
  if git rev-parse --verify HEAD >/dev/null 2>&1
  then
  	against=HEAD
  else
  	# Initial commit: diff against an empty tree object
  	against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
  fi
  if git diff --cached --diff-filter=AM $against -U0 |
     grep "require 'ruby-debug'; debugger" > /dev/null
  then
  	echo "Error: You twit, you've left a debugger in!"
    	exit 1
  fi

And checking for master should be done like this:

  test "master" == "$(git rev-parse --abbrev-ref HEAD)"

And probably not by grep'ing the output of symbolic-ref.

Again, for stuff like this, take a look at git itself. Some fairly major parts of it (such as rebase) are still shell scripts, and the stuff that's once was shell scripts can be found in git.git/contrib/examples

You also don't need to look at every commit with git log. Just look at the commits you haven't pushed presumably with:

  git log -i -E --grep='[[:<:]]wip[[:>:]]' @{upstream}..

You'll notice I also grep'ed for "wip" (as a stand-alone word) with log itself, though this matches anywhere in the commit message, not just the subject. Add --author to this if you like, and maybe --oneline | grep '...' if you further want to grep to just the subject.

The git man pages are a decent reference for this kind of stuff.

Good point. It did start as something akin to that and I forgot that over time I've adapted the approach to catch things left in by other developers (and already committed to the codebase).

Given the catching the debug statement is limited to my very specific usage, your suggestion would be more suitable.

I noticed he uses the env trick for his shebang for ruby. I was first acquainted with this for Perl, and I've since more or less stopped using it since it caused about as many problems for me as it solved (funny thing, systems with the perl binary in a silly place sometimes have env in the 'wrong' place too :/). I'm kind of surprised that it made the jump to Ruby, since to my knowledge it came into use after the Ruby community had already finished borrowing from Perl that which it was going to borrow.

But foo is more likely to jump around than env, right?

I'd like someone else to make up my mind on this. Please discredit the env approach in any way possible :-)

Would love some more discussion on this too, to discredit either approach. I've gone with the env approach precisely because I've found the only other ways I know to be even more brittle.

Since using RVM on multiple machines I've found I cannot assume a fixed, universal path to the ruby interpreter, so env is the choice for me.

I've also never had an issue with env itself not being where I expect it, but if I ever do I think a symlink addition would solve the problem.

It's not just Ruby. I regularly see (and use) it in Python scripts, too. Hell, sometimes I use env for my shell scripts, just out of habit.

For me this comes out as dark blue print on a dark blue background - I have to highight text to make it visible, let alone readable.

That can't be what was intended ...

Should be fixed now

It is - thanks - excellent response.

I don't like workflow enforcement in git commits; I commit broken/failing code as a safety net in case I really break it later.

More: http://blog.brycekerley.net/post/1082060161/pre-commit-hooks... (and http://news.ycombinator.com/item?id=1669583 )

I don't commit anything with failing tests as a matter of principle. I want to be able to revert any commit at any point in the future and have some degree of confidence that the code should be in a working state.

Any "failing" tests in your workflow would be marked as pending rather than actually failing.

This. The one thing that creeps me out about git is that it encourages you to use the index to make partial commits which don't match any state your working copy has ever been in. If I don't know whether that revision actually worked, I don't want it polluting my history and making useful revisions hard to find.

That's what I use the feature-xyz branch for. I make "incomplete" commits, by logic only (refactor this, add new function...) and then at the merge into the develop branch, the commit must be in a working state. That way my development branch is always in a working state and each commit there adds one thing at a time (and still I have the detailled look because I use --no-ff commit).

On a related note: git-hooks seem like a better way to enforce workflow than something like git-flow which got a lot of press here in the last few weeks.

Personally, I'd much rather have something prompt me and say "you're about to push to a remote master from a feature branch, are you sure you want to do this?" rather than using a new set of high-level abstractions such like 'git make-release'.

Reply on news.ycombinator.com