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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html