Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > Let's look at what happens. Let's say that your history looks like > > ... -> A -> B -> C -> a -> b -> c > > where the upper-case letters are from the tree you track, and the > lower-case letters are the commits you added yourself. > > Now, let's say that the tree you track gets rebased, and in the process > 'B' is removed (because it turns out it was buggy), and A and C get > modified. What happens? > > You now have > > ... -> A -> B -> C -> a -> b -> c <- your branch > \ > other stuff -> A' -> C' <- newly rebased branch > > (where "other stuff" is whatever the remote branch was rebased on top > of) and when you now try to rebase your stuff on top of the newly rebased > branch, you are going to end up trying to rebase all the _old_ commits > that weren't even yours (ie it's going to try to rebase A, B and C too!) > ... > What you can do is to basically do > > git fetch nasty-tree > git rebase C.. --onto nasty-tree > > ie you can explicitly _tell_ rebase which commits you want to rebase. Which if I am reading git-rebase.sh right (mind you, this is not my code, so I may well be mistaken), that is what "pull --rebase" attempts to do with the "oldremoteref" variable. -- 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