Other Software > Developer's Corner

Diff before commit

(1/2) > >>

phitsc:
I was discussing this question with a colleague recently and we were of quite opposite opinions. I'm a proponent of diffing before commit, I consider it to be kind of my personal mini code review. He basically considers it to be a waste of time, saying that he knows what he changed and that he's just committing very often (which I try to do as well, by the way, but never mind).

I'd like to know how you people feel about this question.

Shades:
For me 'Diff before commit' is THE golden rule, with the 'Commit often' rule a very close second.

It is definitely not a waste of time, because you will lose a lot more time when reviewing bigger pieces from other developers and how their changes will affect yours.

You can use 'lazy methods' for coding...never for committing!

f0dder:
Depends on what I've been doing.

If I've been working on something for hours before committing, I definitely do look at diffs in order to write a proper commit message. For shorter-interval commits, the changes are usually small enough that I can remember all of what I've been working on. The more often I commit, the less need I have for looking at diffs. Also helps a lot to work on a single feature at a time (I need to force myself in the habit of doing that - take note if I find other stuff that needs bugfixing/refactoring and modify that after a feature is complete, or do it in a second branch).

A few times, the pre-commit diff has caught silly bugs... but that has always been tied to not committing often enough.

Eóin:
When doing a commit through TortoiseGit, it lists the changed files and double clicking on one shows a diff. So I usually check the diffs only if I spot something out of place in the file list.

housetier:
I always diff every single file before commiting. I don't make exceptions, I have caught many mistakes this way.

Since I also commit often, the changesets are small so it is easily and quickly done.

I find it difficult to believe for someone to know of all the changes that were made. I know that not double-checking will lead to mistakes: our company hired subcontractors and we regularly had to remove their debug statements and such from the code (only if we saw them).

In our team we do several things:

* branch early
* branch often
* commit early
* commit often
* push early
* push often
Of course before you can push you have to pull, but our git server will remind us :)

I was praised for the quality my work and got a raise recently. I will continue to double check every change, every file. "diff" can save you a lot of trouble!

Navigation

[0] Message Index

[#] Next page