Hacker News Reader

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 )

View on HN

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

Reply on news.ycombinator.com