> No, but I'm shocked git is so misunderstood that this would be considered a time to do this. You shouldn't be. As you say, you shouldn't need to do this, but

> No, but I'm shocked git is so misunderstood that this would be considered a time to do this. You shouldn't be. As you say, you shouldn't need to do this, but the fact that so many people do feel the need to do this speaks to poor UI design on git's part. There are, I think, two main reasons why people feel the need to do this. The first is that git makes it really easy to rewrite history, without really offering much in the way of safety rails. You have but to be burned by this once to lose all trust in git whatsoever. And this is something where there are safer ways to rewrite history: Mercurial's concept of phases or changeset evolution is easily far better than git in this regard. Even exporting the excised revisions as a revset ("strip-backup") is far easier for me to undo than having to go into git reflog (especially because I don't need to race any `git gc` command--note that git is the only VCS that feels the need to have a garbage collector!). The second issue is that git has a lot of different places where state can be hiding, and it quickly becomes unclear which of the various places a command is affecting. Is this going to update my working directory, the most recent commit, the staging area, or multiple of those copies? If I'm in the middle of an interactive rebase, do I need to `git commit` or `git commit --amend` or some other command to properly update "the" commit? Maybe if you're fluent in git, it's all obvious, but if you're not fluent, it's way too easy to accidentally do the wrong thing. And looking up git documentation doesn't help--it's the only tool I regularly use where reading the documentation actively leaves me more confused than before I consulted it.