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