Thread (1 message) 1 message, 1 author, 2016-06-15

Re: nicer frontend to get rebased tree?

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:45:12

Linus Torvalds [off-list ref] writes:
On Fri, 22 Aug 2008, Andi Kleen wrote:
quoted
Well git fetch does nothing by itself.
Git fetch does exactly what it should do by itself. 

If you think it does "nothing", you're really confused.

It updates the "remote" branches - the ones you are downlaoding.
quoted
Sorry that's what I though initially too. But that's wrong.  Just clone
e.g. linux-next and then try to update it with pull a day later.  
You SHOULD NOT DO THAT!

linux-next is not a tree that you can track. It's a tree that you can 
fetch _once_ and then throw away.

So what you can do is to "fetch" linux-next, and test it. But you MUST 
NEVER EVER use it for anything else. You can't do development on it, you 
cannot rebase onto it, you can't do _anything_ with it.
Except perhaps if you are maintaining your own set of patches on top of
"last official release from Linus", you can test merge your changes into
the tip of linux-next of the day and make sure you are in good shape.

Of course you need to discard the test merge after doing so. 

An obvious question I can foresee is "What if I had conflicts in the test
merge, and have to resolve it to see if my changes still work?  I'd
want to rebase so that I do not have to resolve the conflict again when
linux-next matures and gets into Linus's tree.  Now you tell me not to
rebase onto it.  What should I do?"

My tentative answer is "don't worry, rerere will help you next time", but
there may be better options.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help