From: Junio C Hamano Date: Sun, 24 Aug 2008 00:30:01 GMT Subject: Re: nicer frontend to get rebased tree? Message-ID: <7vzln3w8za.fsf@gitster.siamese.dyndns.org> In-Reply-To: Linus Torvalds 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.