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

linux@horizon.com writes:

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.

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.

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

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.