This right there is the what gives me pause. Every time I need to do something out of the box, I need to start googling. Rather than there being an easy to remember command to do it, one that has a good name that indicates what it does; or, more specifically, what one uses it to accomplish. It's like naming a field "list" in code; I know it's a list... but name it so I know what is in it or what it's for.

And to add to the fun, there's multiple other answers in this thread on how to accomplish the same task.

  git reset --soft HEAD^
  # make changes so index only contains what you want
  git commit -a -C ORIG_HEAD

of if you prefer:

  git config --global alias.undo reset --soft HEAD^
  git config --global alias.redo commit -a -C ORIG_HEAD

then:

  git undo
  # make changes so index only contains what you want
  git redo

You could use -c (--reedit-message=) instead of -C (--reuse-message=) for further flexibility.

ORIG_HEAD is set to point to the most recent HEAD when using reset. See "man git-reset" > EXAMPLES > "Undo a commit and redo".

Isn't "undo" too ambiguous to be useful?

Or do you imagine it as a subcommand with further parameters to describe what to undo and how?

I think a term like undo is a mistake if you think of the git history like accounting. There is, or there should be, no such thing as undo the way an unsophisticated layperson imagines they want. Instead undos are just changes like any other changes.

You don't fix entry errors by actually editing history, you make a new entry that both reverses the error and explains why.

If that leads to having to think about some problems a bit non-intuitively, I'm pretty tempted to just say tough shit, it's worse to try to simplify something if simpler really only means wrong and incomplete.

Perhaps undo was just a bad example of a git failing. There certainly are commands that could be more scrutable without becoming incomplete or wrong. But I only see it as an unavoidable process of development. It's not possible for anything to spring forth fully baked, and so it's pointless and wrong to complain that it didn't happen. So the crappiness of the early versions (of whatever, in general, not git in particular) is not damning and nothing else can ever be any different. Then the next, almost as unavoidable, at least certainly natural and typical, is that the process of imporoving necessarily means changing, and that leads to both redundancy and inconsistency. 4 different ways to do something because there is the old way and the next way and the next way...

I see only that git could improve some things in only the way is unavoidable and applies to everything everywhere, and is not a special git failing but simply life, and that most of the perceived complexity of git comes straight from the underlying job we need it to do. It may not be logically possible to have a fundamentally simple tool to do this complex job, only a simple tool that only actually does a simple job, which isn't good enough.

The best I even consider to wish for is just improvement over time figuring out more consistent interfaces and improving the predictability so that you can be more confident in understanding "when I say X, what will actially happen?".

I get what you mean, but really, the command is rewinding the index backwards in time by one ”snapshot”, i.e. commit, which is not a snapshot in the meaning that it would contain the entire filesystem tree at time of commit.

> cp file newFile, I don’t need to know

Depends on what you intend to do with that file.

If you’re fine with the British Railways approach / eventual consistency and don’t need distributed file access, I suppose you don’t need to know.