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

[linux@horizon.com]

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.