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.

linux@horizon.com writes:

Well, if you do a pull without tracking branch, like Linus seems to do, there is no non-fast-forward error. Also, repositories prepared with git-clone from 1.5.0 by default will have tracking branches of forcing kind. I.e. the fetch configuration will specify tracking with '+' in front:

	[remote "origin"]
		fetch = +refs/heads/*:refs/remotes/origin/*

so non-fast-forward check will not trigger in general.

I think I should have made it more obvious, but the emphasis of my proposed rewording is not about removing the word "git gets confused" in order to defend git.

It is very likely to confuse Alice (especially if she did not have any 'a' commits), having to do the merge. But I think the confusion is just a symptom, and the real disease lies elsewhere. The real disease is that it is wrong for me to force the merge on Alice, from the workflow perspective, and that is true even if we were lucky and Alice did not get confused about the merge (e.g. 'j' and 'h' series did not have anything related, and/or 'a' really fixed up 'j'). In any case, Alice should not to have to worry about what happened between 'j' and 'h' forks, and I think the document should emphasize that point.