

Slaying dragons with git, bash, and ruby - glenngillen
http://rubypond.com/blog/slaying-dragons-git-bash-ruby

======
js2
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

~~~
js2
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

------
KaeseEs
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.

~~~
frou_dh
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 :-)

~~~
glenngillen
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.

~~~
jamesbritt
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.

------
RiderOfGiraffes
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 ...

~~~
glenngillen
Should be fixed now

~~~
RiderOfGiraffes
It is - thanks - excellent response.

------
bonzoesc
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...](http://blog.brycekerley.net/post/1082060161/pre-commit-hooks-arent-
a-good-place-to-test) (and <http://news.ycombinator.com/item?id=1669583> )

~~~
glenngillen
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.

~~~
prodigal_erik
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.

~~~
patrickg
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).

------
dschobel
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'.

