Hacker News Reader

Came out of private mode on my phone to upvote this.

One key point I'd like to add though is that you must _always_ run git diff before committing anything. There's been enough times where that has saved me from erraneously committing logging statements that are absolutely unnecessary post bug fix.

View on HN

You can also use a different function for temporary debug prints, and a git pre-commit hook that fails if this function is invoked.

Pros: Easier to insure that your collaborators follow process; your CI server can run it too.

Con: This doesn't catch other issues that a manual `git diff` review will also catch.

Getting into the habit of always adding via `git add -p` is useful to stop this from happening.

Yea commiting by hunks is also super useful. I find a lot of engineers only have a cursory understanding of a lot of git. Rebase vs merge throws a lot of people off and not a lot of people know about git bisect which is just incredibly useful. I think some of it is that people like the graphical nature of things like sourcetree which while offering pretty interfaces don't fully flesh out git. Give me the command line any day.

It's better to do the big commit and then refactor it. Otherwise you won't have tested whether the hunks depend on each other, which means history littered with broken commits.

Reply on news.ycombinator.com