[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0804301513350.2980@woody.linux-foundation.org>
Date: Wed, 30 Apr 2008 15:19:44 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andrew Morton <akpm@...ux-foundation.org>
cc: Dmitri Vorobiev <dmitri.vorobiev@...il.com>, rjw@...k.pl,
davem@...emloft.net, linux-kernel@...r.kernel.org,
jirislaby@...il.com, mingo@...e.hu
Subject: Re: Slow DOWN, please!!!
On Wed, 30 Apr 2008, Andrew Morton wrote:
> > For busy (or lazy) people like myself, the big problem with linux-next are
> > the frequent merge breakages, when pulling the tree stops with "you are in
> > the middle of a merge conflict".
>
> Really? Doesn't Stephen handle all those problems? It should be a clean
> fetch each time?
It should indeed be a clean fetch, but I wonder if Dmitri perhaps does a
"git pull" - which will do the fetch, but then try to _merge_ that fetched
state into whatever the last base Dmitri happened to have.
Dmitry: you cannot just "git pull" on linux-next, because each version of
linux-next is independent of the next one. What you should do is basically
# Set this up just once..
git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
and then after that, you keep on just doing
git fetch linux-next
git checkout linux-next/master
which will get you the actual objects and check out the state of that
remote (and then you'll normally never be on a local branch on that tree,
git will end up using a so-called "detached head" for this).
IOW, you should never need to do any merges, because Stephen did all those
in linux-next already.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists