Hacker News Reader

That is most definitely a major issue of this technique, though it can probably be mitigated through various hooks.

I find this technique great to keep unrelated fixes in separate commits. A single revision may not pass a set of unit tests, but the entire feature branch will before being merged into the release line. Keeping the barrier low for committed code is one of git's best features.

> Keeping the barrier low for committed code is one of git's best features.

When I first learned git, I was told, 'You'll never have to comment out code again'. Keeping the barrier for commits low (along with git -p and git rebase -i) makes this a reality.

> A single revision may not pass a set of unit tests, but the entire feature branch will before being merged into the release line

I really don't care a whit about your feature branch when your broken commits mean I can't bisect an issue.

Reply on news.ycombinator.com