Re: Why is it bad to rewind a branch that has already been pushed out?

You're quite right that git's basic history model won't get confused, just the users might be.

The basic problem is that, if you rewind your series from j to j^, and Alice has already fetched it, she'll get an error when she tries to fetch it again and git notices that j -> h is not a fast-forward.

It's not the error per se that's the problem, but the potentially confusing condition that git fetch justifiably refuses to let you get into without explicit authorization.

Heck, it could be a security breach, which is the main reason that it's an error and not a warning.

It won't confuse git, but might confuse Alice.

How about:

 Be careful with that last command: in addition to losing any changes
 in the working directory, it will also remove all later commits from
 this branch.  If this branch is the only branch containing those
-commits, they will be lost.  (Also, don't use "git reset" on a
-publicly-visible branch that other developers pull from, as git will
-be confused by history that disappears in this way.)
+commits, they will be lost.  Also, avoid using "git reset" on a
+publicly-visible branch that other developers have pulled from,
+because git (deliberately) has no way to "pull back" the commits
+they've already seen.  Git can cope with the resultant mess, but
+it can be confusing.