> The other difference is that I'm "rebasing" onto an ancestor of the current head, as in I'm not really changing base at all.

`rebase -i` doesn't restrict that, does it? There may be people whose workflow includes things like `git rebase -i --onto foo bar baz`. That you don't use it is another matter.

> A hypothetical new command would be a simpler version of "rebase" that comes with the restriction described above, that it's not actually changing base.

You want to remove features from git? Why?

If you didn't mean to say that instead of having `rebase -i` we should only have this hypothetical command, then you can do:

  git config --global alias.edit-history 'rebase -i'

Though you may want to add to that to make it impossible to use edit-history to rebase, too. I mean, you did say you wanted the restriction, right?

No, rebase -i doesn't, that's why I said `rebase -i HEAD~x` in my original comment and not just `rebase -i`. `rebase -i` should of course continue to exist.

Your right when you say I don't "just" want to introduce an alias because I want to restrict the arguments.

The other issue with that solution is I don't just want a solution for me. I know how this works now, I've already memorized the magic incantation to edit history and later spent the time to understand why the command does what it does (the same goes for basically all the other common git commands). What I want is a solution that works for everyone, out of the box, so we can stop wasting time teaching git internals.