Although their effects are superseded (B^{tree} == M^{tree}), they are still in the ancestry chain.
To a downstream person who were lucky enough not to have made commits on A yet, next pull from you would have involved merging B and A.
If the upstream did not do the magic "ours" merge, the git-fetch step would refuse to update the remote tracking branch head, so the downstream person needs to force the fetch. After forcing the fetch, the merge would have involved resolving the conflicts coming from 3-way merge in this:
o---o---o---A---N
/ /
---o---o---o---o---o---B---'Because the forked track leading to B was either to fix mistakes or clean things up the upstream originally did in the track leading to A, the commits on the tracks leading to A and B from their fork point are almost guaranteed to have conflicting changes, and resolution of that conflict is forced on the downstream person. Worse yet, from this point on, since the upstream discarded the track that contains A, the branch downstream person has will _never_ converge to upstream branch, even though the downstream person did _no_ development of his own in the meantime. This is *B*A*D*.
If there is a magic "ours" merge, the downstream person's repository records A as the last tip on the tracking branch, and git-fetch sees the updated head M is a descendant of it, so it simply fast-forwards:
o---o---o---A
/ \
---o---o---o---o---o---B---MNow, if the downstream was unlucky and have commits based on A, the story is a bit different, but the principles are the same.
Without the "ours" merge M, you will get this:
o---o---o---A---X---N
/ /
---o---o---o---o---o---B-------'When creating the merge N, even if the change between A and X (i.e. the downstream's own work) does not touch the paths that differ between A and B, the downstream is forced to resolve conflicts between A and B. This is unnecessary burden for him. The upstream should have cleaned up his own mess.
With the "ours" merge M, you will get this:
o---o---o---A---X---N
/ \ /
---o---o---o---o---o---B---M---'The downstream does not need to worry about the conflicts between A and B. It has been already resolved at M. Especially, if the change between A and X does not touch the paths that differ in A and B, conflict resolution would be purely about his own work.
In either case, since the downstream has his own development, the heads of their branches never converge until the upstream buys his changes (i.e. pull from the downstream that has "N" commit), but that is not a problem but a feature and does not have anything to do with this "oops, rewound by mistake" issue.
