Re: nicer frontend to get rebased tree?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 24, 2008, 00:30 UTC
- Message-ID
- <7vzln3w8za.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <alpine.LFD.1.10.0808231440530.3363@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 28 quoted lines
> 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.