Distrusting git
benno.id.au
benno.id.au
I remember when I discovered recursive merge. Turned it off straight away. Testing on a specific kind of code base with 16k test cases isn't that much better than 'untested'.
I like merge conflicts - they don't destroy my productivity and make me feel secure that my SCM isn't stepping beyond its bounds - automatic merges are always dangerous, even if they work 99.9% of the time - the time when it destroys two people's works more than makes up for that (this has happened to me with p4v and git in real world scenarios near a deadline).
I've always had a hard time with git though to be fair... but no problems with mercurial. It started with an installer where it was easy to accidentally download the source repo over my metered connection... 'Linux quality software' for sure.
The more I've learned about how git works the more I don't want to use it. :/
In general: commit before you start doing major tree/history manipulation stuff like merging; committing is what makes your data really secure! This is not a subtle point, it's merely common sense, and because of git's "commits are lightweight, local, and amendable" model, there's little excuse not to commit.
[It seems somewhat likely this person was used to subversion, which has much more heavyweight commits and a more limited model, and thus requires doing more stuff while in an uncommitted state. But "like subversion" is not synonymous with "good practice."]
It re-inforces the need for task branches. And don't merge into uncommited code.