4 ms·

Slaying dragons with git, bash, and ruby

57 points by glenngillen 16y ago

RiderOfGiraffes 16y ago
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 16y ago
  Should be fixed now
  - RiderOfGiraffes 16y ago
    It is - thanks - excellent response.
js2 16y ago
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
- glenngillen 16y ago
  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.
- js2 16y ago
  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.
- js2 16y ago
  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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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.
- xiongchiamiov 16y ago
  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.
dschobel 16y ago
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'.
bonzoesc 16y ago
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-arent-a-good-place-to-test http://blog.brycekerley.net/post/1082060161/pre-commit-hooks... (and http://news.ycombinator.com/item?id=1669583 http://news.ycombinator.com/item?id=1669583 )
- glenngillen 16y ago
  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 16y ago
    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 16y ago
      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).

57 points by glenngillen 16y ago

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 16y ago
Should be fixed now
- RiderOfGiraffes 16y ago
  It is - thanks - excellent response.

js2 16y ago

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

glenngillen 16y ago
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.
js2 16y ago
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.
js2 16y ago
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 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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.
xiongchiamiov 16y ago
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.

dschobel 16y ago

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

bonzoesc 16y ago

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

glenngillen 16y ago
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 16y ago
  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 16y ago
    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).