4 ms·

That’s solved by writing good commit messages from the start. Commiting junk or WIP is an easily fixable culture problem.

• pdimitar 5y ago
  That's not realistic at all. Programmers are often times "in the zone" and having to craft perfect messages while you're rushing on to the next problem is killing productivity. Compromises with human nature must be made. Hence -- we need to be able to rewrite history. Your academic purism is out of place, dude. Real humans don't work like you say they do. Some do -- most don't.
• azernik 5y 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.
  • chousuke 5y ago
    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.
    • azernik 5y ago
      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.