Hacker News new | ask | show | jobs
by azernik 1839 days ago
Exactly. You should not commit WIP.

By definition the actual history of your work includes WIP, so this means your commit history should not reflect the actual history of your work.

1 comments

I'm of the opinion that you should commit WIP stuff. Use the SCM for managing your source code, damn it!

Just don't publish WIP crap; fortunately, you can have your cake and eat it too, with git.

The biggest reason git (and any similarly advanced SCM) is superior to non-distributed alternatives like Subversion is that I can use it to manage my own workflow, instead of just as the final off-site backup of whatever I decide to publish. I get to actually use everything git offers for shuffling commits and code around while coding.

Want to switch contexts quickly? git commit the whole thing and just switch a branch.

How about untangling a hairy merge? Do it piecemeal and commit when you're done with each bit; it's trivial to then undo mistakes, redo, combine or reorder stuff and you cannot lose any work by accident because git commits are immutable.

All of these features essentially require history rewriting; sure, you're free to rebrand and not call "store WIP state in repository" a commit even though it is one, but I would consider any SCM without these features nigh useless for most work.

That was indeed my point; this started out with someone saying git is bad because rewriting history is bad, and me pushing back on that.