Re: nicer frontend to get rebased tree?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux