linux@xxxxxxxxxxx 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. - 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