Does it make sense to commit after every save with a DVCS?

Question

I know the question has been asked before how often to commit with a DVCS. All answers have one thing in common--as often as possible. But they're usually something like, after finishing a thought, a user story, getting code that compiles, or passing tests. I was thinking, given that a DVCS gives you you're own repository, with very cheap commits, doesn't it make sense, to commit after every change to a file? After all, this is what happens in NetBeans, and you get a nice free "time machine" without even asking for it. If not every change, then at least every save, or compile.

Does this make sense, or do I have the wrong idea about DVCS. My feeling is that this not the workflow most people have with DVCS.

Answer 1

I use the awesome git-wip tool for users of git and emacs. It makes a commit each time I save, but it makes the commit in a side branch. The automatic commits don't become a part of the history on the main branch and consequently are normally not propagated to other repositories.

It lets met look back through my previous saves easily, but without cluttering my regular branch with non-working commits. Best of both worlds.

Answer 2

You should certainly try to avoid comitting code which does not work, and perhaps even does not compile (I think even if you clean up hisory with git rebase --interactive before pushing / publishing code). Otherwise value of git bisect to find bugs would get greatly diminished.

You can use git commit + git commit --amend (or e.g. stg refresh if you use StGIT patch management interface¹) to snapshot your code without introducing commits with non-working core.

The rule of thumb is that commit should do one thing, do it well, and do it completely.

---

Footnotes

^1. Or equivalent for other patch management interfaces, like Guilt for Git, or Mercurial Queues (mq) extension distributed with Mercurial, which was inspiration for Guilt.