Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Fri, 22 Aug 2008, Andi Kleen wrote: >> >> 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. > >> 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. -- 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
