if you are satisfied with CVS/SVN version - any commit is final and there is no way to undo or modify them - then you don't need reflog. If you mess up, you just say: "oh well this sucks" and leave commit in place. This is what I was doing back when I used SVN and CVS.

hg has similar thing but it's different for each command. For example to undo "hg strip" you manually dig into .hg/strip-backups directory.. I never understand why people call it more intuitive.

Can't tell you anything about bzr, never used it.

Not really. I think of it as git’s undo button. I don’t criticize my word processor for being so complex that it needs an undo button.

That analogy is verging on dishonest. A word processor’s undo button is typically used in service of the operator’s thought process, as it pertains to their actual output, not how they’re using the word processor. The analogue to this is git itself.

I said typically though. We all know the “you move an image in Word and your layout completely changes” meme. Sometimes someone wants to undo something because the tool didn’t do what they intended. Even though I have no empirical basis beyond my no experience, I am incredibly confident that the typical use of Undo in a word processor is because the operator has changed their mind about what they want their output to be, rather than because they had already concluded what they want the end result to be and they just can’t get the software to do it. I have to imagine that you agree with this.

So yes, be thankful that git has reflog. All other things equal, git with reflog is better than git without. I don’t see how your analogy invalidates or refutes the the critique that typical use of git’s reflog is as a result of the operator not knowing how to use git. And to simply say “you’re holding it wrong”, when ‘holding’ git routinely involves standing due East at the next full moon, is absurd.

A person who isn’t “good at” word processors will use it both when they change their mind and when the program doesn’t do what they want (e.g. I didn’t realize that I had a text selection before I started typing and now my selected text is deleted). It’s the same with git, and now we are just arguing about what’s “typical”. An example of when I change my mind about what I told the program to do, maybe when rebasing I decide my merge resolution wasn’t actually what I wanted. That is certainly in the “user changed their mind” class of error.

I’m not saying git has a great user interface that users intuitively grok and rarely make mistakes in. But I am saying that having an undo button is not an admission of that, either.

The point is that other tools achieve the same with less complexity in the users mental model.

If you use the undo button because your word processor doesn't do what you want a lot, maybe look for a word processor that's better designed.

Because we insist on telling people to Rebase as part of the standard workflow, which is just a huge footgun for people who dont understand what they are doing.

I haven't used reflog in probably 2-3 months but it's just a small thing to know it doesn't hurt.